Re: [RFC 0/1] drm/mm: Introduce address space shifting

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

 



Am 04.03.25 um 16:39 schrieb Lis, Tomasz:
> There was no NACK, and no further questions/comments for a month.
>
> From that, we conclude that the proposed change is considered acceptable.

Well there was also not any comment from Arun nor Matthew who are the de facto maintainers for this particular code.

Saying that the whole change looks completely unecessary and overly complex to me.

Just maintain the offset for your VF separately to the drm_mm nodes and you don't need to change all nodes any more when that offset changes.

Going to comment on the other reply as well.

Regards,
Christian.

>
> In case anyone disagrees, please respond now.
>
> We are starting work on a series which will use the proposed drm_mm function.
>
> -Tomasz
>
> On 04.02.2025 23:41, Tomasz Lis wrote:
>> This RFC asks for introduction of an interface which allows to shift
>> a range managed by drm_mm instance without repeating the node list
>> creation.
>>
>> The long explanation:
>>
>> Single Root I/O Virtualization is becoming a standard GFX feature
>> in server environments. Virtual Machines provided with direct access
>> to virtualized GFX hardware, in form of VFs, need to support the
>> standard set of features expected by Virtual Machine Managers.
>> These standard features include ability to save the VM state, and
>> later restore the VM, possibly on another machine with different
>> setup. For the restore to succeed, the GFX hardware model must match;
>> but for its configuration, some differences are often allowed. Such
>> alterations may include a different range of non-virtualized
>> resources assigned to the VF, including global address spaces.
>>
>> If any non-virtualized address space is saved, as part of VM state,
>> on one machine and restored on another, it may happen that the target
>> range differs from source range. To shift the address space,
>> currently creating a new drm_mm object is required, and moving all
>> nodes to the new object while adding the shift.
>>
>> GFX hardware handled by Xe driver contains Global Graphics
>> Translation Table, which is an example of such non-virtualized
>> resource. Should this interface change be accepted, a series which
>> utilizes this interface in Xe driver will be prepared.
>>
>> Signed-off-by: Tomasz Lis <tomasz.lis@xxxxxxxxx>
>>
>> Tomasz Lis (1):
>>    drm_mm: Introduce address space shifting
>>
>>   drivers/gpu/drm/drm_mm.c | 24 ++++++++++++++++++++++++
>>   include/drm/drm_mm.h     |  1 +
>>   2 files changed, 25 insertions(+)
>>




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux