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

[Lis, Tomasz]

On 05.02.2025 09:32, Christian König wrote:
> Am 04.02.25 um 23:41 schrieb Tomasz Lis:
>> 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.
>
> What do you mean with "shift" here? As far as I can see from the code 
> you just modify the start address of each node, e.g. you manipulate 
> the offset.

Yes, that's the idea - move the address space to a different base.

Should I use different terminology?


>
>> 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.
>
> Well that sounds exactly like what AMD is doing, but we just add the 
> VRAM base to the MM node when calculating the final address in the MC 
> address space.
>
> On the other hand AMD hardware has different address spaces, e.g. VRAM 
> in page table always starts at address 0 while in the MC address space 
> it has a certain offset which differs from device to device.

We use the drm_mm in a similar manner - some address spaces start at 0, 
other use a narrower range. But we do not add any base after creation - 
we have the nodes at final offsets.

There is one more technique we use in few places to restrict range of 
valid addresses - we create "balloon" nodes which fill up the 
inaccessible areas. When the accessible range shifts, we then remove all 
notes, and add them back with balloons resized and the rest of nodes 
just moved by an offset.

Using the function proposed in this RFC will actually force us to 
abandon the ballooning approach for VF Global Gfx Translation Table 
address space and refactor the code to give only the accessible range to 
drm_mm. That is why I'm sending the RFC without use example - we will 
have to refactor the Xe code to use it.

-Tomasz

>
> Regards,
> Christian.
>
>>
>> Signed-off-by: Tomasz Lis <tomasz.lis at intel.com>
>>
>> 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(+)
>>
>