> -----Original Message----- > From: Joonas Lahtinen [mailto:joonas.lahtinen@xxxxxxxxxxxxxxx] > Sent: Thursday, April 13, 2017 6:11 PM > To: Li, Weinan Z <weinan.z.li@xxxxxxxxx>; Chris Wilson <chris@chris- > wilson.co.uk> > Cc: intel-gfx@xxxxxxxxxxxxxxxxxxxxx; intel-gvt-dev@xxxxxxxxxxxxxxxxxxxxx > Subject: Re: [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@xxxxxxxxxxxxxxx] > > > Sent: Wednesday, April 12, 2017 6:19 PM > > > To: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>; Li, Weinan Z > > > <weinan.z.li@xxxxxxxxx> > > > Cc: intel-gfx@xxxxxxxxxxxxxxxxxxxxx; > > > intel-gvt-dev@xxxxxxxxxxxxxxxxxxxxx > > > Subject: Re: [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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
