On 11/22/2017 01:13 PM, Cornelia Huck wrote:
+ object_class_property_add_bool(klass, "cssid-unrestricted",
+ prop_get_true, NULL, NULL);
This looks really, really strange. This is a property that is always
true if it exists.
Won't argue about that. The libvirt guys are actually not interested
int he value at all: only that there is such a property.
So what about a machine property? Wouldn't that help as well?
Technically it is doable. The property would be still a weird
one, but from QEMU perspective in a less weird place. I was also
arguing that from OO perspective this kind of a don't care about
it's value property is weird, but AFAIK not having the info if
we can do something with a device at the device is weird from
Libvirt perspective. I'm really uncomforble with speaking for
Libvirt/Boris. Hope he will make his point tomorrow.
Or a css object?
My first internal-only version used this approach, but
I was asked to do it like this.
If we formulate this rather as "we now expose the default css", we (a)
have something that really makes the most sense at a channel subsystem
or machine level, and (b) can be detected by libvirt as an indicator of
"no restriction for virtual vs. non-virtual".
I think that there are good reasons for using a device property as well
as for using a machine property. Technically both options are possible
(even for libvirt :) without too much rope...). At first my personal
choice was to express the changed behavior/capability on the device
level since that is what a user defines on the command line and also
where he gets restricted to use a css matching his device type.
From the libvirt perspective we would have supported vfio-ccw devices
only if the vfio-ccw would be allowed to be defined with unrestricted
cssids.
As I wrote before I also understand the reasoning to express the channel
subsystem wide changed behavior as a machine option. In that case
libvirt would need to check that both capabilities (vfio-ccw and machine
option cssid-unrestricted) are set and not just
vfio-cww.cssid-unrestricted. All doable. A qemu command line user would
obviously need to know the correlation of the machine option and the ccw
devices but that certainly is also nothing new.
When talking to Christian and Halil I started to favor the idea of a new
css object especially when thinking about the future in which the user
might want to specify the default css. It for sure would also be able to
be set with the use of a machine option but a css object would at that
point be much a nicer and more capable approach. What do you think?
--
Mit freundlichen Grüßen/Kind regards
Boris Fiuczynski
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martina Köderitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
