Re: [Xen-devel] [PATCH 5/7] public / x86: introduce __HYPERCALL_iommu_op

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

> From: Paul Durrant [mailto:Paul.Durrant@xxxxxxxxxx]
> Sent: Tuesday, February 27, 2018 5:33 PM
> 
> > -----Original Message-----
> [snip]
> > > I'll define some terms to try to avoid confusing...
> > >
> > > - where the IOMMU code in Xen maintains a map such that BFN == MFN,
> > > let’s call this an 'identitity MFN map'
> > > - where the IOMMU code in Xen *initially programmes* the IOMMU
> with
> > > an identity MFN map for the whole host, let's call this a 'host map'
> > > - where the IOMMU code in Xen maintains a map such that BFN == GFN,
> > > let's call this an 'identity GFN map'
> > > - where the IOMMU code in Xen *initially programmes* the IOMMU
> with
> > > an identity GFN map for the guest, let's call this a 'guest map'
> >
> > Can you introduce a name for such mapping? then when you describe
> > identity mapping in future version, people can immediately get the
> > actual meaning. At least to me I always think about the mapping on
> > actual IOMMU page table first, which is always about BFN->MFN
> > mapping (where the definition of BFN varies in different usages).
> >
> 
> My point is that there are two notional types of identity map: one where
> BFN == MFN and one where BFN == GFN. Then there is whether Xen
> maintains the map, or just programmes it at domain create and thereafter
> leaves it alone.
> 
> > >
> > > > 1) for dom0 (w/o pvIOMMU) in strict mode, it's MFN:MFN identity
> > > mapping
> > >
> > > Without strict mode, a host map is set up for dom0, otherwise it is an
> > > identity MFN map. In both cases the xen-swiotlb driver is use in Linux as
> > > there is no difference from its point of view.
> > >
> > > > 2) for dom0 (w/ pvIOMMU), it's BFN:MFN mapping
> > >
> > > With PV-IOMMU there is also a host map but since a host map is only
> > > initialized and not maintained (i.e. nothing happens when pages are
> > > removed from or added to dom0) then it is safe for dom0 to control the
> > > IOMMU mappings as it will not conflict with anything Xen is doing.
> >
> > what do you mean by not maintained?
> 
> By 'maintained' I mean that, when the P2M of the guest is modified, Xen
> will adjust the IOMMU mappings accordingly.
> 
> > host map will be programmed
> > to IOMMU page table before launching Dom0, since hypervisor doesn't
> > know whether there will be a pvIOMMU driver launched. Later
> > pvIOMMU driver is loaded and issues hypercall to control its own
> > mapping, hypervisor then switch IOMMU page table from host map
> > to the new one, which is the same logic regarding to virtual VTd for
> > HVM guest. that is how I call an address space switch.
> 
> But that is not what happens. If need_iommu() is false then Xen will have
> programmed a mapping (BFN == MFN in the case of dom0), but will not
> touch it after that. Whether the domain (dom0 in this case) chooses to
> modify those mapping after that is up to the domain.... but it is free to do
> so because Xen will not dynamically adjust the mapping should the P2M
> change.
> With PV-IOMMU there is no 'big switch'; Xen does nothing more than set
> up the initial mapping and then respond to the individual map/unmap
> hypercalls that the domain may or may not issue.

I prefer to Xen doing an ownership switch, i.e. clear all initial mappings
before serving pvIOMMU request. otherwise pvIOMMU driver needs to
unmap the whole address space itself before serving any map/unmap
requests from other drivers, which is counterintuitive to what a normal
IOMMU driver would do (just initialize an empty page table).

> 
> >
> > >
> > > > 3) for HVM (w/o virtual VTd) with passthrough device, it's GFN:MFN
> > >
> > > I have not been following virtual VTd closely but, yes, as it stands *when
> > > h/w is passed through* the guest gets an identity GFN map otherwise it
> > > gets no map at all.
> > >
> > > > 4) for HVM (w/ virtual VTd) with passthrough device, it's BFN:MFN
> > > >
> > >
> > > With virtual VTd I'd expect there would be a guest map and then the
> guest
> > > would get the same level of control over the IOMMU that PV-IOMMU
> > > allows for a PV domain but, of course, such control is as-yet unsafe for
> > > guests since an IOMMU fault can cause a host crash.
> >
> > I'm not sure why you call it unsafe. even today with any passthrough
> > device (w/o virtual VTd exposed), a bad guest driver can always cause
> > DMA access to invalid GPA address and thus cause IOMMU fault. adding
> > virtual VTd doesn't change any security aspect here.
> 
> That's not entirely true. Xen could easily fill the IOMMU with a BFN == GFN
> mapping for valid GFN and then program all the other BFN to point at a
> scratch page and thus avoid any possibility of an IOMMU fault caused by an
> in-guest driver mis-programming a device. As soon as Xen gives the domain
> control over its own mappings then it can no longer ensure all BFN map to
> something valid.

Please note Xen never gives the domain control on the actual IOMMU page
table. w/ either pvIOMMU or virtual VTd, the map/unmap operations
are always validated by Xen and then reflected in IOMMU page table. In this
regard, nothing prevents Xen from doing similar trick - programming
invalid BFNs to pointing to scratch page, same as for GFN, and then later
replaced with guest-expected mapping upon map/unmap request.

There is no architectural difference between w/ and w/o virtual VTd.
same for pvIOMMU.

> 
> >
> > >
> > > > (from IOMMU p.o.v we can always call all 4 categories as BFN:MFN.
> > > > I deliberately separate them from usage p.o.v, where 'BFN'
> > > > represents the cases where guest explicitly manages a new address
> > > > space - different from physical address space in its mind)
> > > >
> > > > there is an address space switch in 2) and 4) before and after
> > > > enabling vIOMMU.
> > >
> > > Is there? The initial mapping in 2 is the same as 1, and the initial
> mapping in
> > > 4 is the same as 3.
> > >
> > > >
> > > > above is why I didn’t follow the assumption that "Xen is maintaining
> > > > an identity map" is identical to need_iommu.
> > > >
> > >
> > > The crucial point is that in cases 2 and 4 Xen is not *maintaining* any
> map
> > > so need_iommu(d) should be false and hence the domain can control
> its
> > > own mappings without interfering which what Xen is doing internally.
> > >
> > > Does that help clarify?
> > >
> >
> > again, above description is really confusing as you don't specify
> > which mapping is referred to here.
> >
> 
> That's because the actual mapping is irrelevant here. Do you now
> understand the difference between Xen setting up an initial mapping and
> Xen maintaining that mapping (by keeping it synchronized with the P2M)?
> That's what the need_iommu(d) flag is all about.... it has nothing to do with
> whether the mapping is identity MFN or identity GFN, or something
> different.
> 

Though I understand the way that you are describing, saying "Xen is 
maintaining an identity map" without any decoration explaining
'identity' for what did generate confusion. In IOMMU context, identity 
mapping w/o any decoration imo always refers to the IOMMU page table 
by default. If you intend it to mean something different, then please 
elaborate it in the code comment.

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