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