Re: [Xen-devel] [RFC 0 PATCH 3/3] PVH dom0: construct_dom0 changes

[Mukesh Rathor <mukesh.rathor@xxxxxxxxxx>]

On Fri, 4 Oct 2013 16:59:53 -0400
Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> wrote:

> On Fri, Oct 04, 2013 at 05:07:59PM +0100, Jan Beulich wrote:
> > >>> On 04.10.13 at 18:02, Konrad Rzeszutek Wilk
> > >>> <konrad.wilk@xxxxxxxxxx> wrote:
> > > So back to hooking up a new hypercall in the PCI subsystem when
> > > resource assigment has been completed? And also if the PCI
> > > subsystem decides to re-write the resource addresses to odd
> > > locations.
> > > 
> > > Can't one also trap for the configuration changes on the PCI
> > > devices and extract the physical locations then?
> > 
> > Yes, of course we could be snooping the CFG writes, but that's
> > as simple as it sounds only for the port CF8 based accesses. For
> > MCFG based accesses it would mean we'd have to write protect
> > the whole MCFG range, and use emulation there. Not very
> > pretty, but doable.
> 
> Hypervisor call is then a more appropiate if it can be done (Mukesh
> says that v0 of the patch had something like that in so he will try
> to recreate it) and then as a fallback we could do the emulation.

Right, looks like it has to be guest driven. xen can provide the
facility via the PHYSDEVOP_map_iomem I had in V0. For linux, we will do 
such mappings above the highest e820 entry via the ioremap path. 

As a result of this, we don't need to change pvh_map_all_iomem() and
it will continue to map upto the highest e820 entry. I will change
the comment:

 * PVH FIXME: The following doesn't map MMIO ranges when they sit above the
 *            highest E820 covered address.

to

 * Note: we map the ranges upto 4GB or the last e820 entry, whichever is
 *       higher. Any ranges beyond are mapped by the guest via
 *       PHYSDEVOP_map_iomem.

thanks
Mukesh


diff -r 774a211e6b8f -r 2c728d96f876 xen/arch/x86/physdev.c
--- a/xen/arch/x86/physdev.c    Wed Jan 30 12:30:34 2013 -0800
+++ b/xen/arch/x86/physdev.c    Mon Jan 28 15:30:45 2013 -0800
@@ -740,6 +740,25 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_H
         break;
     }
 
+    case PHYSDEVOP_map_iomem : {
+
+       struct physdev_map_iomem iomem;
+        struct domain *d = current->domain;
+
+        ret = -EPERM;
+        if ( !IS_PRIV(d) || !is_pvh_domain(d))
+            break;
+        d = rcu_lock_current_domain();
+        
+        ret = -EFAULT;
+        if ( copy_from_guest(&iomem, arg, 1) != 0 )
+            break;
+
+       ret = domctl_memory_mapping(d, iomem.first_gfn, iomem.first_mfn, 
+                                   iomem.nr_mfns, iomem.add_mapping);
+        break;
+    }
+
     default:
         ret = -ENOSYS;
         break;
diff -r 774a211e6b8f -r 2c728d96f876 xen/include/public/physdev.h
--- a/xen/include/public/physdev.h      Wed Jan 30 12:30:34 2013 -0800
+++ b/xen/include/public/physdev.h      Mon Jan 28 15:30:45 2013 -0800
@@ -330,6 +330,20 @@ struct physdev_dbgp_op {
 typedef struct physdev_dbgp_op physdev_dbgp_op_t;
 DEFINE_XEN_GUEST_HANDLE(physdev_dbgp_op_t);
 
+ 
+/* Map given gfns to mfns where mfns are part of IO space. */
+#define PHYSDEVOP_map_iomem        30
+struct physdev_map_iomem {
+    /* IN */
+    uint64_t first_gfn;
+    uint64_t first_mfn;
+    uint32_t nr_mfns;
+    uint32_t add_mapping;        /* 1 == add mapping;  0 == unmap */
+
+};
+typedef struct physdev_map_iomem physdev_map_iomem_t;
+DEFINE_XEN_GUEST_HANDLE(physdev_map_iomem_t);
+
 /*
  * Notify that some PIRQ-bound event channels have been unmasked.
  * ** This command is obsolete since interface version 0x00030202 and is **



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