| 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(+) >
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@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(+)