| Message ID | 20250204224136.3183710-1-tomasz.lis@intel.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | drm/mm: Introduce address space shifting | expand |
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. > 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. Regards, Christian. > > Signed-off-by: Tomasz Lis <tomasz.lis@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(+) >
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@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(+)