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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 12.09.18 at 12:09, <Paul.Durrant@xxxxxxxxxx> wrote:
>>  -----Original Message-----
>> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> Sent: 12 September 2018 11:08
>> 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:30, <Paul.Durrant@xxxxxxxxxx> wrote:
>> >>  -----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?
>> 
>> 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.

Jan



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