Re: [Xen-devel] [PATCH v5 12/15] x86: add iommu_op to enable modification of IOMMU mappings

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

> From: Paul Durrant [mailto:Paul.Durrant@xxxxxxxxxx]
> Sent: Tuesday, August 7, 2018 4:33 PM
> 
> >
> > > From: Paul Durrant
> > > Sent: Saturday, August 4, 2018 1:22 AM
> > >
> > > This patch adds an iommu_op which checks whether it is possible or
> > > safe for a domain to modify its own IOMMU mappings and, if so,
> creates
> > > a rangeset to track modifications.
> >
> > Have to say that there might be a concept mismatch between us,
> > so I will stop review here until we get aligned on the basic
> > understanding.
> >
> > What an IOMMU does is to provide DMA isolation between devices.
> > Each device can be hooked with a different translation structure
> > (representing a different bfn address space). Linux kernel uses this
> > mechanism to harden kernel drivers (through dma APIs). Multiple
> > devices can be also attached to the same address space, used by
> > hypervisor when devices are assigned to the same VM.
> >
> 
> Indeed.
> 
> > Now with pvIOMMU exposed to dom0, , dom0 could use it to harden
> > kernel drivers too. Then there will be multiple bfn address spaces:
> >
> > - A default bfn address space created by Xen, where bfn = pfn
> > - multiple per-bdf bfn address spaces created by Dom0, where
> > bfn is completely irrelevant to pfn.
> >
> > the default space should not be changed by Dom0. It is attached
> > to devices which dom0 doesn't enable pviommu mapping.
> 
> No that's not the point here. I'm not trying to re-architect Xen's IOMMU
> handling. All the IOMMU code in Xen AFAICT is built around the assumption
> there is one set of page tables per-VM and all devices assigned to the VM
> get the same page tables. I suspect trying to change that will be a huge can
> of worms and I have no need to go there for my purposes.

don't just think from Xen side. think about what Dom0 feels about
this IOMMU.

ideally pviommu driver is a new vendor driver attached to iommu
core within dom0. it needs to provide iommu dma ops to support
dma_alloc/map operations from different device drivers. iommu
core maintains a separate iova space for each device, so device
drivers can be isolated from each other. 

Now dom0 got only one global space. then why does dom0 need
to enable pviommu at all?

> 
> >
> > per-bdf address spaces can be changed by Dom0, attached to
> > devices which dom0 enables pviommu mapping. then pviommu ops
> > should accept a bdf parameter. and internally Xen needs to maintain
> > multiple page tables under dom0, and find a right page table according
> > to specified bdf to complete the operation.
> >
> > Now your series look assuming always just one bfn address space
> > cross all assigned devices per domain... I'm not sure how it works.
> >
> 
> It does make that assumption because that assumption is baked into Xen's
> IOMMU support.
> 
> > Did I misunderstand anything?
> 
> Only perhaps that moving away from per-VM IOMMU pagetables will be
> something that is something I could do without making very invasive and
> lengthy changes to Xen's IOMMU code.
> 

it's a must imo.

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