From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: One question about the hypercall to translate gfn to mfn. Date: Tue, 9 Dec 2014 11:29:03 +0000 Message-ID: <1418124543.14361.27.camel@citrix.com> References: <5486CAAF.9070807@linux.intel.com> <20141209104633.GC75319@deinos.phlegethon.org> <9AAE0902D5BC7E449B7C8E4E778ABCD025785885@AMSPEX01CL01.citrite.net> <1418123464.14361.19.camel@citrix.com> <9AAE0902D5BC7E449B7C8E4E778ABCD025785926@AMSPEX01CL01.citrite.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <9AAE0902D5BC7E449B7C8E4E778ABCD025785926@AMSPEX01CL01.citrite.net> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Paul Durrant Cc: Kevin Tian , "Keir (Xen.org)" , "Tim (Xen.org)" , "Xen-devel@lists.xen.org" , "Yu, Zhang" , "JBeulich@suse.com" List-Id: xen-devel@lists.xenproject.org On Tue, 2014-12-09 at 11:17 +0000, Paul Durrant wrote: > > -----Original Message----- > > From: Ian Campbell > > Sent: 09 December 2014 11:11 > > To: Paul Durrant > > Cc: Tim (Xen.org); Yu, Zhang; Kevin Tian; Keir (Xen.org); JBeulich@suse.com; > > Xen-devel@lists.xen.org > > Subject: Re: [Xen-devel] One question about the hypercall to translate gfn to > > mfn. > > > > On Tue, 2014-12-09 at 11:05 +0000, Paul Durrant wrote: > > > > -----Original Message----- > > > > From: Tim Deegan [mailto:tim@xen.org] > > > > Sent: 09 December 2014 10:47 > > > > To: Yu, Zhang > > > > Cc: Paul Durrant; Keir (Xen.org); JBeulich@suse.com; Kevin Tian; Xen- > > > > devel@lists.xen.org > > > > Subject: Re: One question about the hypercall to translate gfn to mfn. > > > > > > > > At 18:10 +0800 on 09 Dec (1418145055), Yu, Zhang wrote: > > > > > Hi all, > > > > > > > > > > As you can see, we are pushing our XenGT patches to the upstream. > > One > > > > > feature we need in xen is to translate guests' gfn to mfn in XenGT dom0 > > > > > device model. > > > > > > > > > > Here we may have 2 similar solutions: > > > > > 1> Paul told me(and thank you, Paul :)) that there used to be a > > > > > hypercall, XENMEM_translate_gpfn_list, which was removed by Keir in > > > > > commit 2d2f7977a052e655db6748be5dabf5a58f5c5e32, because there > > was > > > > no > > > > > usage at that time. > > > > > > > > It's been suggested before that we should revive this hypercall, and I > > > > don't think it's a good idea. Whenever a domain needs to know the > > > > actual MFN of another domain's memory it's usually because the > > > > security model is problematic. In particular, finding the MFN is > > > > usually followed by a brute-force mapping from a dom0 process, or by > > > > passing the MFN to a device for unprotected DMA. > > > > > > > > These days DMA access should be protected by IOMMUs, or else > > > > the device drivers (and associated tools) are effectively inside the > > > > hypervisor's TCB. Luckily on x86 IOMMUs are widely available (and > > > > presumably present on anything new enough to run XenGT?). > > > > > > > > So I think the interface we need here is a please-map-this-gfn one, > > > > like the existing grant-table ops (which already do what you need by > > > > returning an address suitable for DMA). If adding a grant entry for > > > > every frame of the framebuffer within the guest is too much, maybe we > > > > can make a new interface for the guest to grant access to larger areas. > > > > > > > > > > IIUC the in-guest driver is Xen-unaware so any grant entry would have > > > to be put in the guests table by the tools, which would entail some > > > form of flexibly sized reserved range of grant entries otherwise any > > > PV driver that are present in the guest would merrily clobber the new > > > grant entries. > > > A domain can already priv map a gfn into the MMU, so I think we just > > > need an equivalent for the IOMMU. > > > > I'm not sure I'm fully understanding what's going on here, but is a > > variant of XENMEM_add_to_physmap+XENMAPSPACE_gmfn_foreign which > > also > > returns a DMA handle a plausible solution? > > > > I think we want be able to avoid setting up a PTE in the MMU since > it's not needed in most (or perhaps all?) cases. Another (wildly under-informed) thought then: A while back Global logic proposed (for ARM) an infrastructure for allowing dom0 drivers to maintain a set of iommu like pagetables under hypervisor supervision (they called these "remoteprocessor iommu"). I didn't fully grok what it was at the time, let alone remember the details properly now, but AIUI it was essentially a framework for allowing a simple Xen side driver to provide PV-MMU-like update operations for a set of PTs which were not the main-processor's PTs, with validation etc. See http://thread.gmane.org/gmane.comp.emulators.xen.devel/212945 The introductory email even mentions GPUs... Ian.