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

["Jan Beulich" <JBeulich@suse.com>]

>>> 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. 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).

Jan


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