e 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-
On 01.04.2025 19:24, Michal Wajdeczko wrote:
please use "drm/xe/vf:" in the subject as this patch is still more VF
oriented, then general SRIOV
ok.
On 31.03.2025 15:21, Tomasz Lis wrote:
We have only one GGTT for all IOV functions, with each VF having assigned
a range of addresses for its use
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 (1):
drm_mm: Introduce address space shifting
On 05.03.2025 08:15, Christian König wrote:
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
On 01.04.2025 19:21, Michal Wajdeczko wrote:
Hi Tomasz,
Since we use 'ballooning' concept for GGTT, please include 'GGTT' in the
title to make it more specific
ack
On 31.03.2025 15:21, Tomasz Lis wrote:
The balloon nodes used to fill areas of GGTT inaccessible for
a specific VF, were alloca
On 01.04.2025 19:24, Michal Wajdeczko wrote:
On 31.03.2025 15:21, Tomasz Lis wrote:
Some GuC messages are constructed with incrementing dword counter
rather than referencing specific DWORDs, as described in GuC interface
specification.
This change introduces the definitions of DWORD numbers f
On 01.04.2025 19:25, Michal Wajdeczko wrote:
On 31.03.2025 15:21, Tomasz Lis wrote:
During post-migration recovery of a VF, it is necessary to update
GGTT references included in messages which are going to be sent
to GuC. GuC will start consuming messages after VF KMD will inform
it about fixup
