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

Re: [Xen-devel] [PATCH v6 08/14] vtd: add lookup_page method to iommu_ops


  • To: 'Jan Beulich' <JBeulich@xxxxxxxx>
  • From: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
  • Date: Wed, 12 Sep 2018 09:30:02 +0000
  • Accept-language: en-GB, en-US
  • Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Kevin Tian <kevin.tian@xxxxxxxxx>, George Dunlap <George.Dunlap@xxxxxxxxxx>
  • Delivery-date: Wed, 12 Sep 2018 09:30:08 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHUOsZJOZ4GuCa3qUKycVQRJ81936Tkn9YAgAfQEdD//+JngIAAIbZQgAABdaCAAAD6gP//4WcAgAAhroD//+D8AAAEOIJw///gioD//91ucA==
  • Thread-topic: [PATCH v6 08/14] vtd: add lookup_page method to iommu_ops

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: 12 September 2018 10:21
> To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
> Cc: George Dunlap <George.Dunlap@xxxxxxxxxx>; Kevin Tian
> <kevin.tian@xxxxxxxxx>; xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
> Subject: RE: [PATCH v6 08/14] vtd: add lookup_page method to iommu_ops
> 
> >>> On 12.09.18 at 11:15, <Paul.Durrant@xxxxxxxxxx> wrote:
> >>  -----Original Message-----
> >> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> >> Sent: 12 September 2018 10:13
> >> To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
> >> Cc: George Dunlap <George.Dunlap@xxxxxxxxxx>; Kevin Tian
> >> <kevin.tian@xxxxxxxxx>; xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
> >> Subject: RE: [PATCH v6 08/14] vtd: add lookup_page method to
> iommu_ops
> >>
> >> >>> On 12.09.18 at 11:05, <Paul.Durrant@xxxxxxxxxx> wrote:
> >> >> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> >> >> Sent: 12 September 2018 10:03
> >> >>
> >> >> A HVM guest using the PV IOMMU is quite fine, but it shouldn't talk to
> >> >> it in terms of MFNs.
> >> >>
> >> >
> >> > Well, it has to talk MFNs at some level, surely? The output of the
> IOMMU is
> >> > not subject to EPT/NPT, right?
> >>
> >> Yes to the second question, but no to the first: The GFN -> MFN
> translation
> >> should still be done inside Xen in the HVM case, imo (in the course of
> >> manufacturing the PTE).
> >
> > Indeed. This function is very much internal to Xen (it's simply an
> > abstraction on top of a vendor implementation), so why should it not work
> in
> > terms of MFNs?
> 
> Because "MFN" is a concept a HVM guest is not knowing about, or
> supposed to be knowing. The only time where (part of) it might
> legitimately (have to) know is when it comes to managing the host
> (including any guests), i.e. in the tool stack of a PVH Dom0.

Ok. So consider validating a PV-IOMMU unmap request from an HVM guest. It 
passes in a DFN and a GFN  belonging to itself. Now Xen needs to figure out 
whether that BFN actually maps to the GFN. It can look up the MFN backing the 
GFN (from the p2m). How does Xen now validate it if it cannot lookup what MFN 
is actually present in the PTE referenced by the DFN?

  Paul

> 
> Jan
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

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