Re: [PATCH v2 06/19] iommufd/viommu: Add IOMMU_VIOMMU_SET/UNSET_VDEV_ID ioctl

On Mon, May 05, 2025 at 07:53:44PM -0700, Nicolin Chen wrote:

On Mon, May 05, 2025 at 02:08:07PM -0300, Jason Gunthorpe wrote:

quoted

On Wed, Apr 30, 2025 at 12:58:47AM -0700, Nicolin Chen wrote:

quoted

quoted

... and I just hit a problem with it - this is basically guest BDFn
and it works as long as I'm hotplugging the TEE-IO VF into an SNP VM
but does not when I pass through via the QEMU cmdline - bus numbers
are not assigned yet. So I have to postpone the vdevice allocation
till run time, did I miss something here? Thanks,

I have a similar case with QEMU ARM64's VM: so vDEVICE on ARM is
allocated at runtime as well because the BDF number isn't ready
at the boot time.

Oh that's ugly then.. So you'll need to add some kind of 'modify
sid/bdf' operation I think.

But the initial vDEVICE would be still unusable. Its BDF number is
literally 0 in my case. It can't be used for SID-based invalidation
nor the reverse vSID lookup for fault injection..

That's fine, that is actually what it is in the vPCI topology. Until
the bus numbers are assigned at least.

So you'd have SID conflicts in the kernel, just pick the first one or
something until it gets sorted out.

quoted

The bus numbers can be reassigned at any time on the fly by the guest
by reprogramming the PCI hierarchy.

Yes. If we take some aggressive use case into account, where its
BDF number could change multiple times, I think it's natural for
VMM to simply destroy the previous vDEVICE and allocate a new one
with a new BDF number, right?

We should not destroy the vdevice for something like that. In a CC
case that would unplug it from the VM which is not right.

Jason