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

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
[snip]
> >
> > 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).
> 

I don't think there is any need. I have code happily running that simply 
overwrites the existing mappings. Nothing in the lower layers requires an IOMMU 
PTE to be clear before it is written, no no need for explicit unmap. There is 
also danger in clearing the existing mappings as I have discovered... some 
hosts, including my test host, have undeclared RMRRs inside some of the E820 
reserved regions so completely removing the identity MFN map (leaving only 
RMRRs) causes the machine to lock up. Simply allowing dom0 to write an identity 
GFN map over the top avoids this problem... but I can also a case for starting 
from a 'clean' IOMMU.

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

Yes, true. If Xen always treated unmap operations as 'map to a scratch page' 
then faults could be avoided. Perhaps it would be better to do that rather than 
actually clearing PTEs.

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

Ok, I will expand the comment to fully explain.

  Cheers,

    Paul

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