qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH v4 28/41] vfio/iommufd: Implement the iommufd backend


From: Joao Martins
Subject: Re: [PATCH v4 28/41] vfio/iommufd: Implement the iommufd backend
Date: Thu, 9 Nov 2023 12:59:29 +0000
User-agent: Mozilla Thunderbird

On 09/11/2023 12:57, Jason Gunthorpe wrote:
> On Thu, Nov 09, 2023 at 12:17:35PM +0000, Joao Martins wrote:
>> On 08/11/2023 12:48, Jason Gunthorpe wrote:
>>> On Wed, Nov 08, 2023 at 07:16:52AM +0000, Duan, Zhenzhong wrote:
>>>
>>>>>> +    ret = iommufd_backend_alloc_hwpt(iommufd, vbasedev->devid,
>>>>>> +                                     container->ioas_id, &hwpt_id);
>>>>>> +
>>>>>> +    if (ret) {
>>>>>> +        error_setg_errno(errp, errno, "error alloc shadow hwpt");
>>>>>> +        return ret;
>>>>>> +    }
>>>>>
>>>>> The above alloc_hwpt fails for mdevs (at least, it fails for me 
>>>>> attempting to use
>>>>> iommufd backend with vfio-ccw and vfio-ap on s390).  The ioctl is failing 
>>>>> in the
>>>>> kernel because it can't find an IOMMUFD_OBJ_DEVICE.
>>>>>
>>>>> AFAIU that's because the mdevs are meant to instead use kernel access via
>>>>> vfio_iommufd_emulated_attach_ioas, not hwpt.  That's how mdevs behave when
>>>>> looking at the kernel vfio compat container.
>>>>>
>>>>> As a test, I was able to get vfio-ccw and vfio-ap working using the 
>>>>> iommufd
>>>>> backend by just skipping this alloc_hwpt above and instead passing 
>>>>> container-
>>>>>> ioas_id into the iommufd_cdev_attach_hwpt below.  That triggers the
>>>>> vfio_iommufd_emulated_attach_ioas call in the kernel.
>>>>
>>>> Thanks for help test and investigation.
>>>> I was only focusing on real device and missed the mdev particularity, 
>>>> sorry.
>>>> You are right, there is no hwpt support for mdev, not even an emulated 
>>>> hwpt.
>>>> I'll digging into this and see how to distinguish mdev with real device in
>>>> this low level function.
>>>
>>> I was expecting that hwpt manipulation would be done exclusively
>>> inside the device-specific vIOMMU userspace driver. Generic code paths
>>> that don't have that knowledge should use the IOAS for everything
>>
>> I am probably late into noticing this given Zhenzhong v5; but arent' we
>> forgetting the enforcing of dirty tracking in HWPT is done /via/
>> ALLOC_HWPT ?
> 
> The underlying viommu driver supporting mdev cannot support dirty
> tracking via the hwpt flag, so it doesn't matter.
> 
> The entire point is that a mdev doesn't have a hwpt or any of the hwpt
> linked features including dirty tracking.

I am not talking about mdevs; but rather the regular (non mdev) case not being
able to use dirty tracking with autodomains hwpt allocation.

        Joao



reply via email to

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