Hi Kevin,
On Thu, Nov 22, 2018 at 08:39:19AM +0000, Tian, Kevin wrote:
> 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?
Yeah, thinking more about it, there are no real reasons against allowing
aux and sva bindings on the default domain. It allows the host to use a
device through the DMA-API and assign parts of it to a guest or a
user-space process, for example.
> |-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)
> | |-...
In my proposal the sva-domains are no sub-domains of the default-domain,
they exist on the same level. A device is detached from its default
domain and attached to an sva-domain.
> means same domain can be default on deviceA while being aux on deviceB
> (when assigning pci and mdev to same VM).
As already written in another mail, this raises a couple of questions,
like what happens when the aux-domain itself has other aux-domains bound
to it?
Regards,
Joerg
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
