|
From: | Cédric Le Goater |
Subject: | Re: [PATCH 2/2] vfio/ccw: Don't initialize HOST_IOMMU_DEVICE with mdev |
Date: | Mon, 22 Jul 2024 17:36:54 +0200 |
User-agent: | Mozilla Thunderbird |
On 7/22/24 17:09, Joao Martins wrote:
On 22/07/2024 15:57, Eric Farman wrote:On Mon, 2024-07-22 at 15:07 +0800, Zhenzhong Duan wrote:mdevs aren't "physical" devices and when asking for backing IOMMU info, it fails the entire provisioning of the guest. Fix that by setting vbasedev->mdev true so skipping HostIOMMUDevice initialization in the presence of mdevs.Hmm, picking the two commits that Cedric mentioned in his cover-letter reply [1] doesn't "fail the entire provisioning of the guest" for me. Applying this patch on top of that causes the call from vfio_attach_device() to hiod_legacy_vfio_realize() to be skipped, which seems odd. What am I missing? [1] 4c9a184b-514c-4276-95ca-9ed86623b9a4@redhat.com/">https://lore.kernel.org/qemu-devel/4c9a184b-514c-4276-95ca-9ed86623b9a4@redhat.com/If you are using IOMMUFD it will fail the entire provisioning i.e. GET_HW_INFO fails because there's no actual device/IOMMU you can probe hardware information from and you can't start a guest. This happened at least for me in x86 vfio-pci mdevs (or at least I reproduced it when trying to test mdev_tty) But if you don't support IOMMUFD, then it probably makes no difference as type1 doesn't do anything particularly special besides initializing some static data. The realize is skipped because you technically don't have a physical host IOMMU directly behind the mdev, but rather some parent function related software entity doing that for you. Zhengzhong noticed there were some other mdevs aside from vfio-pci and in an attempt to prevent regression elsewhere it posted for the other mdevs in qemu.
yes. I confirm with : -device vfio-ap,id=hostdev0,sysfsdev=/sys/bus/mdev/devices/8eb8351a-e656-4187-b773-fea4e926310d,iommufd=iommufd0 \ -object iommufd,id=iommufd0 \ -trace 'iommufd*' iommufd_cdev_getfd /dev/vfio/devices/vfio4 (fd=28) iommufd_backend_connect fd=27 owned=1 users=1 iommufd_cdev_connect_and_bind [iommufd=27] Successfully bound device 8eb8351a-e656-4187-b773-fea4e926310d (fd=28): output devid=1 iommufd_backend_alloc_ioas iommufd=27 ioas=2 iommufd_cdev_alloc_ioas [iommufd=27] new IOMMUFD container with ioasid=2 iommufd_cdev_attach_ioas_hwpt [iommufd=27] Successfully attached device 8eb8351a-e656-4187-b773-fea4e926310d (28) to id=2 iommufd_backend_map_dma iommufd=27 ioas=2 iova=0x0 size=0x200000000 addr=0x3fd9ff00000 readonly=0 (0) iommufd_cdev_device_info 8eb8351a-e656-4187-b773-fea4e926310d (28) num_irqs=1 num_regions=0 flags=33 iommufd_cdev_detach_ioas_hwpt [iommufd=27] Successfully detached 8eb8351a-e656-4187-b773-fea4e926310d iommufd_backend_unmap_dma iommufd=27 ioas=2 iova=0x0 size=0x200000000 (0) iommufd_backend_free_id iommufd=27 id=2 (0) iommufd_backend_disconnect fd=-1 users=0 qemu-kvm: -device vfio-ap,id=hostdev0,sysfsdev=/sys/bus/mdev/devices/8eb8351a-e656-4187-b773-fea4e926310d,iommufd=iommufd0: vfio 8eb8351a-e656-4187-b773-fea4e926310d: Failed to get hardware info: No such file or directory Thanks, C.
[Prev in Thread] | Current Thread | [Next in Thread] |