> From: j...@8bytes.org [mailto:j...@8bytes.org]
> Sent: Monday, November 12, 2018 10:56 PM
>
> Hi Jean-Philippe,
>
> On Thu, Nov 08, 2018 at 06:29:42PM +0000, Jean-Philippe Brucker wrote:
> > (1) My initial approach would have been to use the same page tables for
> > the default_domain and this new domain, but it might be precisely what
> > you were trying to avoid with this new proposal: a device attached to
> > two domains at the same time.
>
> My request was about the initial assumptions a device driver can make
> about a device. This assumptions is that DMA-API is set up and
> initialized for it, for everything else (like SVA) the device driver
> needs to take special action, like allocating an SVA domain and attaching
> the device to it.
Hi, Joerg,
I agree special action needs to be taken for everything else (other than
DMA-API), but the point that I didn't get is why the action must be based
a new SVA-type domain, instead of extending default domain with SVA
capability (including related paging structures which are accessed through
new SVA APIs). In the latter case domain-wise attribute (e.g. IRQ mapping)
is naturally shared between capabilities (DMA-API and SVA). There is no
need to create cross-domain connections as two options that you listed
below.
Can you help elaborate more about the motivation behind proposal?
P.S. as you may see from other threads, we support same IOMMU
capabilities (both IOVA and SVA) on vfio-mdev (i.e. aux domain) as ones
on vfio-pci. which leads to below situation following your proposal, if
'AUX' is treated as a separate capability as SVA:
|-default domain (DMA-API)
|-sva domain1 (SVA)
|-sva domain2 (SVA)
|-...
|-sva domainN (AUX, guest DMA-API)
| |- sva domainN1 (AUX, guest SVA)
| |- sva domainN2 (AUX, guest SVA)
| |-...
|-sva domainM (AUX, guest DMA-API)
| |- sva domainM1 (AUX, guest SVA)
| |- sva domainM2 (AUX, guest SVA)
| |-...
Is that what is in your mind? would it cause unnecessary complexities
on handling those layers?
The hierarchy could be simplified if we allow aux domain to carry both
DMA-API and SVA capability:
|-default domain (DMA-API)
|-sva domain1 (SVA)
|-sva domain2 (SVA)
|-...
|-sva domainN (AUX, guest DMA-API, guest SVA)
|-sva domainM (AUX, guest DMA-API, guest SVA)
However doing so cause inconsistency on domain definition. why cannot
default domain have full capability but aux domain can?
Further moving along that road, we could have below (as proposed in
this series):
|-default domain (DMA-API, SVA)
|-sva domainN (AUX, guest DMA-API, guest SVA)
|-sva domainM (AUX, guest DMA-API, guest SVA)
(whether putting aux domains as sub-domain or same level is not big deal)
There each domain could support full DMA translation capabilities (IOVA, SVA,
GPA, GIOVA, etc) with supporting structures together (1st level, 2nd level, irq
mapping, etc.), and new APIs are invented to utilized new capabilities beyond
existing DMA-API in each domain. 'AUX' here becomes a orthogonal way to
those DMA translation capabilities, and is chosen at domain attach time based
on device configuration. means same domain can be default on deviceA while
being aux on deviceB (when assigning pci and mdev to same VM).
Thoughts? :-)
>
> This should of course not break any IRQ setups for the device, and also
> enforcing an ordering is not a good and maintainable solution.
>
> So what you could do here is to either:
>
> 1) Save the needed IRQ mappings in some extra datastructure and
> duplicate it in the SVA domain. This also makes it easier to
> use the same SVA domain with multiple devices.
>
> 2) Just re-use the 'page-tables' from the default domain in the
> sva-domain. This needs to happen at attach-time, because at
> allocation time you don't know the device yet.
>
> I think 1) is the best solution, what do you think?
>
> Btw, things would be different if we could expose SVA through the
> DMA-API to drivers. In this case we could just make the default domain
> of type SVA and be done, but we are not there yet.
>
> Regards,
Thanks
Kevin
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
