[libvirt] [PATCH v2 0/4] New mdev type handling for aggregated resources

Cornelia Huck cohuck at redhat.com
Thu Jul 26 15:59:36 UTC 2018


On Thu, 26 Jul 2018 09:51:26 -0600
Alex Williamson <alex.williamson at redhat.com> wrote:

> On Thu, 26 Jul 2018 17:30:07 +0200
> Cornelia Huck <cohuck at redhat.com> wrote:
> 
> > On Thu, 26 Jul 2018 15:50:28 +0200
> > Erik Skultety <eskultet at redhat.com> wrote:
> > > Since libvirt doesn't have an API to create mdevs yet, this doesn't pose an
> > > issue for us at the moment. I see this adds new optional sysfs attributes which
> > > we could expose within our device capabilities XML, provided it doesn't use a
> > > free form text, like the description attribute does.    
> > 
> > One thing I noticed is that we have seem to have an optional (?)
> > vendor-driver created "aggregation" attribute (which always prints
> > "true" in the Intel driver). Would it be better or worse for libvirt if
> > it contained some kind of upper boundary or so?  
> 
> Ultimately the aggregation value should be fully specified in
> Documentation/ABI, but doesn't the kernel generally use 'Y' or 'N' for
> boolean attributes in sysfs?  Maybe mdev core can handle the attribute
> since it should exist any time the create_with_instances callback is
> provided.

It might make sense to print a number if the driver allows a number of
resources to be aggregated which is not the same as available_instances
(see my reply to the documentation patch).

> 
> > Additionally, would it
> > be easier if the "create" attribute always accepted
> > ",instances=1" (calling the .create ops in that case?)  
> 
> Unless I misunderstand the code or the question, I think this is
> exactly what happens:

Indeed, it does. Let me blame the weather ;)

> If the mdev core supplied the aggregation attribute, then the presence
> of the attribute could indicate to userspace whether it can always
> provide an instance (aggregate) count, even if limited to '1' when 'N',
> for that mdev type. Thanks,
> 
> Alex




More information about the libvir-list mailing list