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

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

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

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

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

  Cheers,

    Paul

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