qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC PATCH 1/1] s390x/css: unresrict cssids


From: Boris Fiuczynski
Subject: Re: [Qemu-devel] [RFC PATCH 1/1] s390x/css: unresrict cssids
Date: Wed, 22 Nov 2017 15:45:56 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]