On 27/2/25 00:12, Jason Gunthorpe wrote:
On Wed, Feb 26, 2025 at 06:49:18PM +0800, Xu Yilun wrote:
E.g. I don't think VFIO driver would expect its MMIO access suddenly
failed without knowing what happened.
What do people expect to happen here anyhow? Do you still intend to
mmap any of the MMIO into the hypervisor? No, right? It is all locked
down?
This patchset expects it to be mmap'able as this is how MMIO gets mapped
in the NPT and SEV-SNP still works with that (and updates the RMPs on
top), the host os is not expected to access these though. TDX will
handle this somehow different. Thanks,
So perhaps the answer is that the VFIO side has to put the device into
CC mode which disables MMAP/etc, then the viommu/vdevice iommufd
object can control it.
Back to your concern, I don't think it is a problem. From your patch,
vIOMMU doesn't know the guest BDFn by nature, it is just the user
stores the id in vdevice via iommufd_vdevice_alloc_ioctl(). A proper
VFIO API could also do this work.
We don't want duplication though. If the viommu/vdevice/vbdf are owned
and lifecycle controlled by iommufd then the operations against them
must go through iommufd and through it's locking regime.
The implementation is basically no difference from:
+ vdev = container_of(iommufd_get_object(ucmd->ictx, cmd->vdevice_id,
+ IOMMUFD_OBJ_VDEVICE),
The real concern is the device owner, VFIO, should initiate the bind.
There is a big different, the above has correct locking, the other
does not :)
Jason
--
Alexey
