Re: [PATCH 01/12] drm/xe/pf: Add function to sanitize VF resources

[Rodrigo Vivi <rodrigo.vivi@intel.com>]

On Tue, Aug 20, 2024 at 08:16:19AM -0500, Lucas De Marchi wrote:
> On Tue, Aug 20, 2024 at 11:38:35AM GMT, Michal Wajdeczko wrote:
> > 
> > 
> > On 19.08.2024 22:47, Lucas De Marchi wrote:
> > > On Fri, Aug 09, 2024 at 06:51:48PM GMT, Michal Wajdeczko wrote:
> > > > +static int pf_sanitize_lmem(struct xe_tile *tile, struct xe_bo *bo,
> > > > long timeout)
> > > 
> > > it took a while to make xe use "vram"... now we are back with lmem in
> > > several places :(
> > > 
> > 
> > it's because GuC ABI is using LMEM terminology
> > 
> > if you really want then I can try to rename implementation side to use
> > 'vram' instead, but question is what to do with debugfs entries that
> > reflects GuC ABI almost 1:1, should it also be named with vram ?
> > 
> > gt0/pf/lmem_spare	-> gt0/pf/vram_spare
> > gt0/vf1/lmem_quota	-> gt0/vf1/vram_quota
> 
> +Rodrigo, +Thomas

Sorry for taking so long here.

I believe we should keep 'lmem' here. It matches guc, sriov, and gt design.

In the past, when i915 was introducing device-memory-ram support, instead
of calling it vram to align with everyone else, we decided to go with the
name 'local memory' that we were seeing a lot in internal docs.

It is good that in Xe we are now aligned with 'vram' to refer for these
device memory (ram). But by spec, 'local memory' is something else.

'Local memory' in general is the memory from VRAM which is not managed
by OS, but only managed by our device driver. However it could also be
carved out from the system ram. And then it can be used by SRIOV and
managed with LMTT (local memory translation table).

So, with this in mind and to avoid the sysfs breakage, I'm in favor
of keeping 'lmem' term where it applies. But maybe worth some
documentation page?


> 
> Lucas De Marchi