[Intel-gfx] [PATCH v3] drm/i915/gvt: return the actual aperture size under gvt environment

[Chris Wilson]

On Mon, May 08, 2017 at 01:18:38PM +0300, Joonas Lahtinen wrote:
> On ma, 2017-05-08 at 02:49 +0000, Li, Weinan Z wrote:
> > Hi Joonas/Chris, do you have any comments?
> > I've asked OCL team for this patch, they also agree to use available aperture size
> > for max allocation buffer definition, code confirmation ongoing.
> 
> The patch title should be corrected to refer to usable aperture size.
> 
> > > -----Original Message-----
> > > From: Li, Weinan Z
> > > Sent: Wednesday, May 3, 2017 8:51 AM
> > > > > To: intel-gfx at lists.freedesktop.org; intel-gvt-dev at lists.freedesktop.org
> > > > > Cc: Li, Weinan Z <weinan.z.li at intel.com>
> > > Subject: [PATCH v3] drm/i915/gvt: return the actual aperture size under gvt
> > > environment
> > > 
> > > I915_GEM_GET_APERTURE ioctl is used to probe aperture size from userspace.
> > > In gvt environment, each vm only use the ballooned part of aperture, so we
> > > should return the actual available aperture size exclude the reserved part by
> > > balloon.
> > > 
> > > v2: add 'reserved' in struct i915_address_space to record the reserved size in
> > > ggtt by balloon.
> > > 
> > > v3: remain aper_size as total, adjust aper_available_size exclude reserved and
> > > pinned. UMD driver need to adjust the max allocation size according to the
> > > available aperture size but not total size.

Only adjusting aper_available_size prevents the immediate breakage wrt
to libdrm_intel, but I'm worried about the fragility of userspace using
this. What is it being used for? I doubt this is the right information
for them, and generally whether it's a correct assumption by userspace.

What happened to reporting the correct size via CONTEXT_PARAM_GTT_SIZE
which doesn't have the same issues with userspace incorrectly using GGTT
for PPGTT?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre