On 22/10/2018 07:53, Tian, Kevin wrote:
From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com]
Sent: Saturday, October 20, 2018 2:12 AM
This is a first prototype adding auxiliary domain support to Arm SMMUv3,
following Lu Baolu's latest proposal for IOMMU aware mediated devices
[1]. It works, but the attach() API still doesn't feel right. See (2)
below.
Patch 1 adapts iommu.c to the current proposal for auxiliary domains.
Patches 2-4 rework the PASID allocator to make it usable for SVA and
AUXD simultaneously. Patches 5-6 add AUXD support to SMMUv3.
When a device can have multiple address space, for instance with PCI
PASID, an auxiliary domain (AUXD) is the IOMMU representation of one
address space. I distinguish auxiliary from "main" domain, which
represents the non-PASID address space but also (at least for SMMUv3)
the whole device context, PASID tables etc.
I'd like to clarify a bit. :-)
a domain can always represent one or more address spaces, where an
address space could be for IOVA or GPA and/or other address spaces for
SVA. Address spaces may be chained together in so-called nested mode.
a domain can be associated with a full device (in BDF granular), and/or
with a partition of a device (say in PASID granular). In the former case,
the domain becomes the master (or primary) domain of the device. In
the latter case, the domain becomes the auxiliary domain of the device.
vendor domain structure may include vendor-specific states which
are applied to device context at attach time, e.g. PASID table (SMMUv3)
if representing as master domain, or PASID value (VT-d scalable mode)
if representing as auxiliary domain.
so the domain definition is never changed with the introduction of
AUXD. 'auxiliary' is a per-device attribute which takes effect when at
domain attach time. A domain is perfectly sane to represent as a
master domain to deviceA and an auxiliary domain to deviceB at the
same time (say when device A and a mdev on deviceB are assigned to
same VM), while supporting one or more address spaces.
To me, that sounds like a very good argument for having separate "attach
as primary domain" and "attach as aux domain" APIs. Say a driver wants
to use multiple aux domains itself to isolate logically-separate
transaction streams, but still also needs to control the main domain for
transactions without PASID (interrupts?) - having to juggle some
invisible device state around multiple iommu_{attach,detach}_group()
calls which look identical but are expected to behave differently at
runtime sounds like a recipe for unmaintainable code.
I don't think it's necessarily safe to assume that
one-struct-device-per-PASID will be the only usage model.
Robin.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
