[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 11/14] arm: implement remap interfaces needed for privcmd mappings.



On Thu, 2012-10-04 at 16:24 +0100, Konrad Rzeszutek Wilk wrote:
> On Thu, Oct 04, 2012 at 04:11:52PM +0100, Ian Campbell wrote:
> > Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
> > ---
> >  arch/arm/xen/enlighten.c |   94 
> > +++++++++++++++++++++++++++++++++++++++++++++-
> >  1 files changed, 92 insertions(+), 2 deletions(-)
> > 
> > diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> > index ba5cc13..9956af5 100644
> > --- a/arch/arm/xen/enlighten.c
> > +++ b/arch/arm/xen/enlighten.c
> > @@ -9,6 +9,7 @@
> >  #include <xen/platform_pci.h>
> >  #include <xen/xenbus.h>
> >  #include <xen/page.h>
> > +#include <xen/xen-ops.h>
> >  #include <asm/xen/hypervisor.h>
> >  #include <asm/xen/hypercall.h>
> >  #include <linux/interrupt.h>
> > @@ -18,6 +19,8 @@
> >  #include <linux/of_irq.h>
> >  #include <linux/of_address.h>
> >  
> > +#include <linux/mm.h>
> > +
> >  struct start_info _xen_start_info;
> >  struct start_info *xen_start_info = &_xen_start_info;
> >  EXPORT_SYMBOL_GPL(xen_start_info);
> > @@ -43,15 +46,102 @@ EXPORT_SYMBOL_GPL(xen_platform_pci_unplug);
> >  
> >  static __read_mostly int xen_events_irq = -1;
> >  
> > +/* map fgmfn of domid to lpfn in the current domain */
> 
> <laughs> Say that really fast a couple of times :-)
> 
> Any way we can explain it a bit more of what each acronym means?

The names come from the x86 PVH version, which has the comment:
/* Map foreign gmfn, fgmfn, to local pfn, lpfn. This for the user space 
 * creating new guest on PVH dom0 and needs to map domU pages. 
 */
Is that preferable? (modulo removing the PVH bit)

> 
> > +static int map_foreign_page(unsigned long lpfn, unsigned long fgmfn,
> > +                       unsigned int domid)
> > +{
> > +   int rc;
> > +   struct xen_add_to_physmap xatp = {
> > +           .domid = DOMID_SELF,
> > +           .u.foreign_domid = domid,
> > +           .space = XENMAPSPACE_gmfn_foreign,
> > +           .idx = fgmfn,
> > +           .gpfn = lpfn,
> > +   };
> > +
> > +   rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp);
> > +   if (rc) {
> > +           pr_warn("Failed to map pfn to mfn rc:%d pfn:%lx mfn:%lx\n",
> 
> How about 'Failed to map pfn (0x%lx) to mfn (0x%lx), rc: %d\n" ?

Sure, need to slip foreign domid in there somewhere now I look at it.

x86 PVH has basically the same print BTW.

> 
> > +                   rc, lpfn, fgmfn);
> > +           return 1;
> > +   }
> > +   return 0;
> > +}
> > +
> > +struct remap_data {
> > +   unsigned long fgmfn; /* foreign domain's gmfn */
> 
> Shouldn't this be called now 'xen_pfn_t' or something.

xen_pfn_t is needed at the hypervisor interface layer, I'm not so sure
about kernel internal use. I guess it can't hurt?

> 
> > +   pgprot_t prot;
> > +   domid_t  domid;
> > +   struct vm_area_struct *vma;
> > +   struct xen_remap_mfn_info *info;
> > +};
> > +
> > +static int remap_pte_fn(pte_t *ptep, pgtable_t token, unsigned long addr,
> > +                   void *data)
> > +{
> > +   struct remap_data *info = data;
> > +   struct xen_remap_mfn_info *savp = info->info;
> > +   struct page *page = savp->pi_paga[savp->pi_next_todo++];
> > +   unsigned long pfn = page_to_pfn(page);
> > +   pte_t pte = pfn_pte(pfn, info->prot);
> > +
> > +   if (map_foreign_page(pfn, info->fgmfn, info->domid))
> > +           return -EFAULT;
> > +   set_pte_at(info->vma->vm_mm, addr, ptep, pte);
> > +
> > +   return 0;
> > +}
> > +
> >  int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
> >                            unsigned long addr,
> >                            unsigned long mfn, int nr,
> > -                          pgprot_t prot, unsigned domid)
> > +                          pgprot_t prot, unsigned domid,
> > +                          struct xen_remap_mfn_info *info)
> >  {
> > -   return -ENOSYS;
> > +   int err;
> > +   struct remap_data data;
> > +
> > +   /* TBD: Batching, current sole caller only does page at a time */
> > +   if (nr > 1)
> 
> Lets also wrap it with WARN_ON?

ACK, needs doing on x86 PVH too then.

> 
> > +           return -EINVAL;
> > +
> > +   data.fgmfn = mfn;
> > +   data.prot = prot;
> > +   data.domid = domid;
> > +   data.vma = vma;
> > +   data.info = info;
> > +   err = apply_to_page_range(vma->vm_mm, addr, nr << PAGE_SHIFT,
> > +                             remap_pte_fn, &data);
> > +   return err;
> >  }
> >  EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range);
> >  
> > +/* Returns: Number of pages unmapped */
> > +int xen_unmap_domain_mfn_range(struct vm_area_struct *vma,
> > +                          struct xen_remap_mfn_info *info)
> > +{
> > +   int count = 0;
> > +
> > +   while (info->pi_next_todo--) {
> > +           struct xen_remove_from_physmap xrp;
> > +           unsigned long rc, pfn;
> > +
> > +           pfn = page_to_pfn(info->pi_paga[info->pi_next_todo]);
> 
> Won't this miss the first pi_next_todo? You did the 'pi_next_todo--' so
> will the compiler decrement it here in this operation or will it do
> when it gets to the 'do' logic of the loop?

It's a post decrement so if pi_next_todo == 1 then the expression in the
while will see 1 (true) but inside the loop we see zero. So we end up
processing elements N-1..0 of the array which is correct.

This is the same as on x86 PVH, so if I'm wrong then that is too.

I mentioned in the PVH thread this morning that I think this interface
should drop pi_next_todo and have a simple for loop based on the number
of pages between vm_start...vm_end here.

> 
> > +
> > +           xrp.domid = DOMID_SELF;
> > +           xrp.gpfn = pfn;
> > +           rc = HYPERVISOR_memory_op(XENMEM_remove_from_physmap, &xrp);
> 
> 'rc' is 'unsigned long'. Is that right? You don't want it to be 'int'?

Hypercalls return unsigned long these days, I think it was considered a
mistake that some didn't. See <25744:47080c965937> in the hypervisor
tree. 

Oh, wait, we are both wrong -- it's a long. I'll fix that...

> 
> > +           if (rc) {
> > +                   pr_warn("Failed to unmap pfn:%lx rc:%ld\n",
> > +                           pfn, rc);
> > +                   return count;
> > +           }
> > +           count++;
> > +   }
> > +   return count;
> > +}
> > +EXPORT_SYMBOL_GPL(xen_unmap_domain_mfn_range);
> > +
> >  /*
> >   * see Documentation/devicetree/bindings/arm/xen.txt for the
> >   * documentation of the Xen Device Tree format.
> > -- 
> > 1.7.2.5



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.