From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mukesh Rathor Subject: Re: [RFC 0 PATCH 3/3] PVH dom0: construct_dom0 changes Date: Fri, 4 Oct 2013 18:06:32 -0700 Message-ID: <20131004180632.214c1669@mantra.us.oracle.com> References: <1380142988-9487-4-git-send-email-mukesh.rathor@oracle.com> <5244064102000078000F69AF@nat28.tlf.novell.com> <20130926171737.071f118f@mantra.us.oracle.com> <524547CF02000078000F73F7@nat28.tlf.novell.com> <20131002175358.5f31579c@mantra.us.oracle.com> <524E820002000078000F8C16@nat28.tlf.novell.com> <20131004133526.GE26673@phenom.dumpdata.com> <524EE76502000078000F8E25@nat28.tlf.novell.com> <20131004160253.GA27398@phenom.dumpdata.com> <524F03FF02000078000F8F4A@nat28.tlf.novell.com> <20131004205953.GA22446@phenom.dumpdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1VSGKP-00028c-3N for xen-devel@lists.xenproject.org; Sat, 05 Oct 2013 01:06:41 +0000 In-Reply-To: <20131004205953.GA22446@phenom.dumpdata.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Konrad Rzeszutek Wilk Cc: xen-devel , keir.xen@gmail.com, Jan Beulich List-Id: xen-devel@lists.xenproject.org On Fri, 4 Oct 2013 16:59:53 -0400 Konrad Rzeszutek Wilk wrote: > On Fri, Oct 04, 2013 at 05:07:59PM +0100, Jan Beulich wrote: > > >>> On 04.10.13 at 18:02, Konrad Rzeszutek Wilk > > >>> 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 **