[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



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

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