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

[Li, Weinan Z]

> -----Original Message-----
> From: Joonas Lahtinen [mailto:joonas.lahtinen at linux.intel.com]
> Sent: Thursday, April 13, 2017 6:11 PM
> To: Li, Weinan Z <weinan.z.li at intel.com>; Chris Wilson <chris at chris-
> wilson.co.uk>
> Cc: intel-gfx at lists.freedesktop.org; intel-gvt-dev at lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/gvt: return the actual aperture size
> under gvt environment
> 
> On to, 2017-04-13 at 01:01 +0000, Li, Weinan Z wrote:
> > >
> > > -----Original Message-----
> > > From: Joonas Lahtinen [mailto:joonas.lahtinen at linux.intel.com]
> > > Sent: Wednesday, April 12, 2017 6:19 PM
> > > To: Chris Wilson <chris at chris-wilson.co.uk>; Li, Weinan Z
> > > <weinan.z.li at intel.com>
> > > Cc: intel-gfx at lists.freedesktop.org;
> > > intel-gvt-dev at lists.freedesktop.org
> > > Subject: Re: [Intel-gfx] [PATCH] drm/i915/gvt: return the actual
> > > aperture size under gvt environment
> > >
> > > On ke, 2017-04-12 at 09:53 +0100, Chris Wilson wrote:
> > > >
> > > > On Wed, Apr 12, 2017 at 04:36:57PM +0800, Weinan Li wrote:
> > > > >
> > > > >
> > > > > I915_GEM_GET_APERTURE ioctl is used to probe aperture size from
> > > userspace.
> > > >
> > > > >
> > > > > Some applications like OpenCL use this information to know how
> > > > > much GM resource can it use.
> > > >
> > > > That's a userspace bug.
> > >
> > > Yes, a new property might be in place. I don't think we can go and
> > > change the meaning of a parameter just like that.
> > >
> > > <SNIP>
> > >
> > Here I don’t want to change the meaning of I915_GEM_GET_APERTURE, but
> > for the ioctl, We need to return the actual available aperture size exclude the
> reserved space by GVT balloon.
> 
> IOCTLs represent the ABI contract we have with userspace. It has previously
> returned size of the aperture, so we can't change it to be something else (like
> the usable size of aperture as proposed here).
> 
> Somebody might be doing an assert that any address in aperture is below
> I915_GEM_GET_APERTURE returned value, which has previously been correct,
> but would be broken after this change. There are also potentially other things
> consuming the aperture than VGT ballooning, so the UMDs would still be
> misbehaving.
> 
> Shouldn't they rather be doing these decisions based on aper_available_size?
> 
Known your mean, if we return the value as below:
-	args->aper_size = ggtt->base.total;
+	args->aper_size = ggtt->base.total - ggtt->base.reserved;
Then userspace may use 'args->aper_size' as the MAX aperture addr, it may cause other issues.
In GVT with balloon the aperture addr still be from 0 to ggtt->base.total.
If it's expected behavior, change the available aperture size may avoid this.
	args->aper_size = ggtt->base.total;
 	args->aper_available_size = args->aper_size - ggtt->base.reserved - pinned;
> Regards, Joonas
> --
> Joonas Lahtinen
> Open Source Technology Center
> Intel Corporation