[PATCH] drm/i915/gvt: adjust for fixed vGPU types

[Zhenyu Wang]

On 2017.02.21 03:45:56 +0000, Tian, Kevin wrote:
> > From: Zhenyu Wang [mailto:zhenyuw at linux.intel.com]
> > Sent: Tuesday, February 21, 2017 11:15 AM
> > 
> > Previous vGPU type create tried to determine vGPU types based on
> > some pre-defined resource sizes which might not be optimal. As
> > we'd like to fix vGPU types for _1, _2, _4 and _8 now, we can generate
> > maxium resource size for each fixed type based on physical resource.
> > 
> > Cc: Kevin Tian <kevin.tian at intel.com>
> > Signed-off-by: Zhenyu Wang <zhenyuw at linux.intel.com>
> > ---
> >  drivers/gpu/drm/i915/gvt/vgpu.c | 15 +++++----------
> >  1 file changed, 5 insertions(+), 10 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/gvt/vgpu.c b/drivers/gpu/drm/i915/gvt/vgpu.c
> > index dcfcce1dc00e..dfa8a99acdfe 100644
> > --- a/drivers/gpu/drm/i915/gvt/vgpu.c
> > +++ b/drivers/gpu/drm/i915/gvt/vgpu.c
> > @@ -75,7 +75,7 @@ int intel_gvt_init_vgpu_types(struct intel_gvt *gvt)
> >  {
> >  	unsigned int num_types;
> >  	unsigned int i, low_avail, high_avail;
> > -	unsigned int min_low;
> > +	unsigned int types[] = {1, 2, 4, 8};
> 
> should we define them in macros?
> 
> > 
> >  	/* vGPU type name is defined as GVTg_Vx_y which contains
> >  	 * physical GPU generation type and 'y' means maximum vGPU
> > @@ -92,22 +92,18 @@ int intel_gvt_init_vgpu_types(struct intel_gvt *gvt)
> >  	 */
> >  	low_avail = gvt_aperture_sz(gvt) - HOST_LOW_GM_SIZE;
> >  	high_avail = gvt_hidden_sz(gvt) - HOST_HIGH_GM_SIZE;
> > -	num_types = 4;
> > +	num_types = sizeof(types) / sizeof(unsigned int);
> > 
> >  	gvt->types = kzalloc(num_types * sizeof(struct intel_vgpu_type),
> >  			     GFP_KERNEL);
> >  	if (!gvt->types)
> >  		return -ENOMEM;
> > 
> > -	min_low = MB_TO_BYTES(32);
> >  	for (i = 0; i < num_types; ++i) {
> > -		if (low_avail / min_low == 0)
> > -			break;
> > -		gvt->types[i].low_gm_size = min_low;
> > -		gvt->types[i].high_gm_size = max((min_low<<3), MB_TO_BYTES(384U));
> > +		gvt->types[i].low_gm_size = low_avail / types[i];
> > +		gvt->types[i].high_gm_size = high_avail / types[i];
> >  		gvt->types[i].fence = 4;
> > -		gvt->types[i].max_instance = min(low_avail / min_low,
> > -						 high_avail / gvt->types[i].high_gm_size);
> > +		gvt->types[i].max_instance = types[i];
> >  		gvt->types[i].avail_instance = gvt->types[i].max_instance;
> > 
> >  		if (IS_GEN8(gvt->dev_priv))
> 
> max_instance is not a fixed one. It depends on available physical
> resource and minimal requirement in guest driver. Simply reporting
> all types in all configurations is meaningless - e.g. what's the point
> of reporting 8vGPUs available on a platform configured with only
> 128MB aperture?
>

As now we have defined a host preserved size, I have another one to
check for that sanity. If want to ignore those limited resource types,
seems we need a low limit value, e.g 32M, any type can't provide that
much would not be provided. Do you think that's feasible?

> I think the agreed policy is to define types in 2's power. But how
> many meaningful types should be reported depends on sort of
> dynamic calculation anyway....
> 

yeah, currently simply equal divided for type's instance number, as
it seems not flexible to choose from some arbitrary defined one. Or
current mdev type is just not flexible for us which can actually have
very different physical resource configuration..

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/intel-gvt-dev/attachments/20170221/8d3f79ec/attachment.sig>