Bare metal SVA allocates IOASIDs for native process addresses. This
should be separated from VM allocated IOASIDs thus under its own set.
This patch creates a system IOASID set with its quota set to PID_MAX.
This is a reasonable default in that SVM capable devices can only bind
to limited user
IOASID users fit into the publisher-subscriber pattern, a system wide
blocking notifier chain can be used to inform subscribers of state
changes. Notifier mechanism also abstracts publisher from knowing the
private context each subcriber may have.
This patch adds APIs and a global notifier chain,
IOASID set refers to a group of IOASIDs that shares the same token.
ioasid_set_data() function is used to attach a private data to an IOASID,
rename it to ioasid_attach_data() avoid being confused with the group/set
concept.
Signed-off-by: Jacob Pan
---
drivers/iommu/intel-svm.c | 11
In bare metal SVA, IOMMU driver ensures that IOASID free call always comes
after IOASID unbind operation.
However, for guest SVA the unbind and free call come from user space
via VFIO, which could be out of order. This patch registers a notifier
block in case IOASID free() comes before unbind
IOASID was introduced in v5.5 as a generic kernel allocator service for
both PCIe Process Address Space ID (PASID) and ARM SMMU's Sub Stream
ID. In addition to basic ID allocation, ioasid_set was introduced as a
token that is shared by a group of IOASIDs. This set token can be used
for permission
IOASID set defines a group of IDs that share the same token. The
ioasid_set concept helps to do permission checking among users as in the
current code.
With guest SVA usage, each VM has its own IOASID set. More
functionalities are needed:
1. Enforce quota, each guest may be assigned limited quota
The current ioasid_alloc function takes a token/ioasid_set then record it
on the IOASID being allocated. There is no alloc/free on the ioasid_set.
With the IOASID set APIs, callers must allocate an ioasid_set before
allocate IOASIDs within the set. Quota and other ioasid_set level
activities can
Each IOASID or set could have multiple users with its own HW context
to maintain. Often times access to the HW context requires thread context.
For example, consumers of IOASIDs can register notification blocks to
sync up its states. Having an atomic notifier is not feasible for these
update
Assign system-wide PASID capacity with enumerated max value.
Currently, all Intel SVM capable devices should support full 20 bits of
PASID value.
Signed-off-by: Jacob Pan
---
drivers/iommu/intel-iommu.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/iommu/intel-iommu.c
IOASID set is allocated with an initial quota, at runtime there may be
needs to balance IOASID resources among different VMs/sets.
This patch adds a new API to adjust per set quota.
Signed-off-by: Jacob Pan
---
drivers/iommu/ioasid.c | 44
IOASID is a limited system-wide resource that can be allocated at
runtime. This limitation can be enumerated during boot. For example, on
x86 platforms, PCI Process Address Space ID (PASID) allocation uses
IOASID service. The number of supported PASID bits are enumerated by
extended capability
Hi Lorenzo,
On 3/25/2020 2:51 PM, Lorenzo Pieralisi wrote:
> On Thu, Feb 27, 2020 at 12:05:39PM +0200, laurentiu.tu...@nxp.com wrote:
>> From: Laurentiu Tudor
>>
>> The devices on this bus are not discovered by way of device tree
>> but by queries to the firmware. It makes little sense to trick
IOMMU user API header was introduced to support nested DMA translation and
related fault handling. The current UAPI data structures consist of three
areas that cover the interactions between host kernel and guest:
- fault handling
- cache invalidation
- bind guest page tables, i.e. guest PASID
IOMMU UAPI can be extended in the future by adding new
fields at the end of each user data structure. Since we use
a unified UAPI version for compatibility checking, a lookup
function is needed to find the correct user data size to copy
from user.
This patch adds a helper function based on a 2D
Having a single UAPI version to govern the user-kernel data structures
makes compatibility check straightforward. On the contrary, supporting
combinations of multiple versions of the data can be a nightmare to
maintain.
This patch defines a unified UAPI version to be used for compatibility
checks
Reuse UAPI version for each UAPI data structure.
This is to avoid supporting multiple version combinations, simplify
support model as we bump up the versions.
Signed-off-by: Liu Yi L
Signed-off-by: Jacob Pan
---
drivers/iommu/intel-iommu.c | 3 ++-
drivers/iommu/intel-svm.c | 2 +-
Hi Jean,
On 3/18/20 12:40 PM, Jean-Philippe Brucker wrote:
> We don't currently support IOMMUs with a page granule larger than the
> system page size. The IOVA allocator has a BUG_ON() in this case, and
> VFIO has a WARN_ON().
>
> It might be possible to remove these obstacles if necessary. If
On 25/03/2020 19:37, Christoph Hellwig wrote:
> On Wed, Mar 25, 2020 at 03:51:36PM +1100, Alexey Kardashevskiy wrote:
This is for persistent memory which you can DMA to/from but yet it does
not appear in the system as a normal memory and therefore requires
special handling anyway
On 2020/3/26 1:55, Jacob Pan wrote:
IOASID set defines a group of IDs that share the same token. The
ioasid_set concept helps to do permission checking among users as in the
current code.
With guest SVA usage, each VM has its own IOASID set. More
functionalities are needed:
1. Enforce quota,
In preparation for restructuring iommu_fwspec, refactor the way we
access the arm_smmu_master_cfg private data to be less dependent on
the current layout.
Signed-off-by: Robin Murphy
---
drivers/iommu/arm-smmu.c | 42 +---
1 file changed, 22 insertions(+), 20
FWIW I believe is is still on the plan for someone here to dust off
the PMU pNMI patches at some point.
Cool. Well I can try to experiment with what Julien had at v4 for now.
JFYI, I have done some more perf record capturing, and updated the
"annotate" and "report" output here
On Thu, Feb 27, 2020 at 12:05:39PM +0200, laurentiu.tu...@nxp.com wrote:
> From: Laurentiu Tudor
>
> The devices on this bus are not discovered by way of device tree
> but by queries to the firmware. It makes little sense to trick the
> generic of layer into thinking that these devices are of
On 2020-03-24 10:08 am, Joerg Roedel wrote:
Hey Robin,
On Mon, Mar 23, 2020 at 04:02:33PM +, Robin Murphy wrote:
Yikes, this ends up pretty ugly, and I'd prefer not have this much
complexity hidden in macros that were intended just to be convenient
shorthand. Would you mind pulling in the
On Wed, Mar 25, 2020 at 03:51:36PM +1100, Alexey Kardashevskiy wrote:
> >> This is for persistent memory which you can DMA to/from but yet it does
> >> not appear in the system as a normal memory and therefore requires
> >> special handling anyway (O_DIRECT or DAX, I do not know the exact
> >>
24 matches
Mail list logo
