qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 2/2] vfio/ccw: Don't initialize HOST_IOMMU_DEVICE with mdev


From: Joao Martins
Subject: Re: [PATCH 2/2] vfio/ccw: Don't initialize HOST_IOMMU_DEVICE with mdev
Date: Mon, 22 Jul 2024 16:09:16 +0100

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.

        Joao



reply via email to

[Prev in Thread] Current Thread [Next in Thread]