On 19/06/2019 01:19, Jacob Pan wrote:
>>> I see this as a future extension due to limited testing,
>>
>> I'm wondering how we deal with:
>> (1) old userspace that won't fill the new private_data field in
>> page_response. A new kernel still has to support it.
>> (2) old kernel that won't recognize the new PRIVATE_DATA flag.
>> Currently iommu_page_response() rejects page responses with unknown
>> flags.
>>
>> I guess we'll need a two-way negotiation, where userspace queries
>> whether the kernel supports the flag (2), and the kernel learns
>> whether it should expect the private data to come back (1).
>>
> I am not sure case (1) exist in that there is no existing user space
> supports PRQ w/o private data. Am I missing something?
>
> For VT-d emulation, private data is always part of the scalable mode
> PASID capability. If vIOMMU query host supports PASID and scalable
> mode, it will always support private data once PRQ is enabled.
Right if VT-d won't ever support page_response without private data then
I don't think we have to worry about (1).
> So I think we only need to negotiate (2) which should be covered by
> VT-d PASID cap.
>
>>> perhaps for
>>> now, can you add paddings similar to page request? Make it 64B as
>>> well.
>>
>> I don't think padding is necessary, because iommu_page_response is
>> sent by userspace to the kernel, unlike iommu_fault which is
>> allocated by userspace and filled by the kernel.
>>
>> Page response looks a lot more like existing VFIO mechanisms, so I
>> suppose we'll wrap the iommu_page_response structure and include an
>> argsz parameter at the top:
>>
>> struct vfio_iommu_page_response {
>> u32 argsz;
>> struct iommu_page_response pr;
>> };
>>
>> struct vfio_iommu_page_response vpr = {
>> .argsz = sizeof(vpr),
>> .pr = ...
>> ...
>> };
>>
>> ioctl(devfd, VFIO_IOMMU_PAGE_RESPONSE, &vpr);
>>
>> In that case supporting private data can be done by simply appending a
>> field at the end (plus the negotiation above).
>>
> Do you mean at the end of struct vfio_iommu_page_response{}? or at
> the end of that seems struct iommu_page_response{}?
>
> The consumer of the private data is iommu driver not vfio. So I think
> you want to add the new field at the end of struct iommu_page_response,
> right?
Yes that's what I meant
Thanks,
Jean
