On Thu, 26 Jul 2018 09:51:26 -0600
Alex Williamson <alex.williamson(a)redhat.com> wrote:
On Thu, 26 Jul 2018 17:30:07 +0200
Cornelia Huck <cohuck(a)redhat.com> wrote:
> On Thu, 26 Jul 2018 15:50:28 +0200
> Erik Skultety <eskultet(a)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