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 13:03:02 +0000
User-agent: Mozilla Thunderbird

On 09/11/2023 12:59, Joao Martins wrote:
> 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.

... without any vIOMMU.



reply via email to

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