[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC 0 PATCH 3/3] PVH dom0: construct_dom0 changes
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |