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

[Paul Durrant <Paul.Durrant@citrix.com>]

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: 12 September 2018 13:39
> To: Paul Durrant <Paul.Durrant@citrix.com>
> Cc: George Dunlap <George.Dunlap@citrix.com>; Kevin Tian
> <kevin.tian@intel.com>; xen-devel <xen-devel@lists.xenproject.org>
> Subject: RE: [PATCH v6 08/14] vtd: add lookup_page method to iommu_ops
> 
> >>> On 12.09.18 at 14:22, <Paul.Durrant@citrix.com> wrote:
> >>  -----Original Message-----
> >> From: Jan Beulich [mailto:JBeulich@suse.com]
> >> Sent: 12 September 2018 13:15
> >> To: Paul Durrant <Paul.Durrant@citrix.com>
> >> Cc: George Dunlap <George.Dunlap@citrix.com>; Kevin Tian
> >> <kevin.tian@intel.com>; xen-devel <xen-devel@lists.xenproject.org>
> >> Subject: RE: [PATCH v6 08/14] vtd: add lookup_page method to
> iommu_ops
> >>
> >> >>> On 12.09.18 at 12:09, <Paul.Durrant@citrix.com> wrote:
> >> >>  -----Original Message-----
> >> >> From: Jan Beulich [mailto:JBeulich@suse.com]
> >> >> Sent: 12 September 2018 11:08
> >> >> To: Paul Durrant <Paul.Durrant@citrix.com>
> >> >> Cc: George Dunlap <George.Dunlap@citrix.com>; Kevin Tian
> >> >> <kevin.tian@intel.com>; xen-devel <xen-devel@lists.xenproject.org>
> >> >> Subject: RE: [PATCH v6 08/14] vtd: add lookup_page method to
> >> iommu_ops
> >> >>
> >> >> >>> On 12.09.18 at 11:30, <Paul.Durrant@citrix.com> wrote:
> >> >> >>  -----Original Message-----
> >> >> >> From: Jan Beulich [mailto:JBeulich@suse.com]
> >> >> >> Sent: 12 September 2018 10:21
> >> >> >> To: Paul Durrant <Paul.Durrant@citrix.com>
> >> >> >> Cc: George Dunlap <George.Dunlap@citrix.com>; Kevin Tian
> >> >> >> <kevin.tian@intel.com>; xen-devel <xen-
> devel@lists.xenproject.org>
> >> >> >> Subject: RE: [PATCH v6 08/14] vtd: add lookup_page method to
> >> >> iommu_ops
> >> >> >>
> >> >> >> >>> On 12.09.18 at 11:15, <Paul.Durrant@citrix.com> wrote:
> >> >> >> >>  -----Original Message-----
> >> >> >> >> From: Jan Beulich [mailto:JBeulich@suse.com]
> >> >> >> >> Sent: 12 September 2018 10:13
> >> >> >> >> To: Paul Durrant <Paul.Durrant@citrix.com>
> >> >> >> >> Cc: George Dunlap <George.Dunlap@citrix.com>; Kevin Tian
> >> >> >> >> <kevin.tian@intel.com>; xen-devel <xen-
> >> devel@lists.xenproject.org>
> >> >> >> >> Subject: RE: [PATCH v6 08/14] vtd: add lookup_page method to
> >> >> >> iommu_ops
> >> >> >> >>
> >> >> >> >> >>> On 12.09.18 at 11:05, <Paul.Durrant@citrix.com> wrote:
> >> >> >> >> >> From: Jan Beulich [mailto:JBeulich@suse.com]
> >> >> >> >> >> 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?
> >> >>
> >> >> I'm afraid I don't understand: The passed in GFN gets translated
> >> >> to an MFN using a p2m lookup. The passed in DFN (which aiui ought
> >> >> to match the GFN anyway on x86) gets translated to an MFN using
> >> >> an IOMMU page table lookup. The resulting two MFNs have to
> >> >> match for the request to be valid.
> >> >>
> >> >
> >> > Quite. So how does that work if iommu_lookup_page() is ASSERTing
> that
> >> the
> >> > domain in question is not HVM?
> >>
> >> Well, as soon as the function doesn't hand back MFNs anymore to
> >> HVM callers, no such assertion would be needed anymore either.
> >
> > So you'd prefer I add an ASSERTion that I'm going to remove as soon as I
> add
> > a caller of the function?
> 
> No. I guess I'm increasingly confused: The function at present returns
> MFNs. Hence it must not be called by a HVM guest.

That's the part I don't get. What do you mean by 'called by a HVM guest'? I completely agree that MFN values must not be exposed to an HVM guest so there is no way the output of this function should ever be exposed through a hypercall and I'm not proposing that ever be done.

> Either you assert
> that the calling domain isn't HVM, or you make the function return GFNs
> for HVM domains (which then is a no-op due to gfn == dfn here, at
> least for now).
> 

The function will never return its results to a guest, PV or HVM, so I really don't see the concern. It's a low level function, for Xen's internal use only. It's essentially the equivalent of a p2m lookup function and there's no way we'd ever expose the results of such a lookup to the guest either.

  Paul

> Jan


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