Thread (60 messages) 60 messages, 7 authors, 27d ago

Re: [RFC PATCH v4 03/16] iommu/arm-smmu-v3: Add initial pSMMU realm viommu plumbing

flat view

From: Nicolin Chen <hidden>
Date: 2026-09-01 17:36:34
Also in: kvmarm, linux-coco, lkml

On Tue, Sep 01, 2026 at 02:47:04PM +0530, Aneesh Kumar K.V wrote:
Nicolin Chen [off-list ref] writes:
quoted
But, on the other hand, I can imagine that a Realm VSMMU would add
a new flag with a user_data to this VIOMMU. Then, this flow would
give some troubles to VMM (QEMU for example):

 - For VM with a guest-level SMMU, QEMU creates a realm instance
   where IOMMU_VIOMMU_TYPE_ARM_REALM_SMMUV3 (with vsmmu) can be
   allocated.
 - For VM w/o a guest-level SMMU, QEMU won't create such a realm
   instance, while still required to invoke the ioctl (w/o vsmmu). 

Taking a step back, I wonder if we really need to use iommufd for
PSMMU activation and its stream table allocations?

Here are some facts:
  - An iommufd has a ctx, that's one per VM. Similarly, a Realm
    has an RD.
  - For an RMI command that needs an RD, it makes sense to be per
    iommufd ctx, e.g. RMI_VSMMU_* or RMI_VDEV_* commands.
  - PSMMU commands are global; they don't need RD. So they don't
    seem necessary to tie to an iommufd ctx.

Instead, could the PSMMU activation be done after RMI_PSMMU_INFO
check? Is there any reason not to do that? A safer timing might
be at the device assignment stage?
One of the reasons I added IOMMU_VIOMMU_TYPE_ARM_REALM_SMMUV3 was to
avoid creating a psmmu object when we are not using a PCI passthrough
VM. That is also the reason for all the refcounting around the psmmu
objects.

If we are okay with creating psmmu objects early, then I guess we can go
with the above approach.
Do you see any trouble if we implement in this way:
 - Add "struct arm_smmu_realm *psmmu" in struct arm_smmu_device
 - RMI_PSMMU_INFO in probe():
   + allocate a smmu->psmmu on success
   + keep smmu->psmmu->users = 0; psmmu is not activated
 - Device binds to iommufd, creating idev
   + invoke an iommu op to a driver-level callback:
	psmmu = smmu->psmmu;
	if (!psmmu)
		return 0;
	guard(mutex)(&psmmu->mutex);
	if (!smmu->psmmu->users)
		rmi_psmmu_activate();
	psmmu->users++;
	rmi_psmmu_st_l2_create();
?

Nicolin
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help