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