[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [qemu-s390x] [RFC PATCH 1/1] s390x/css: unresrict cssids
From: |
Cornelia Huck |
Subject: |
Re: [qemu-s390x] [RFC PATCH 1/1] s390x/css: unresrict cssids |
Date: |
Wed, 22 Nov 2017 17:25:22 +0100 |
On Wed, 22 Nov 2017 15:45:56 +0100
Boris Fiuczynski <address@hidden> wrote:
> 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.
Thanks, I can now understand where that property came from.
> 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?
I think exposing the css object and making the default_css property
available is the cleanest solution (especially if we want more css
properties in the future). The only drawback I see is that it needs
more coding (and probably care to keep it backwards compatible.)
Halil, do you think you can come up with something?
- Re: [qemu-s390x] [RFC PATCH 1/1] s390x/css: unresrict cssids, (continued)
Re: [qemu-s390x] [RFC PATCH 1/1] s390x/css: unresrict cssids, Halil Pasic, 2017/11/21
- Re: [qemu-s390x] [RFC PATCH 1/1] s390x/css: unresrict cssids, Cornelia Huck, 2017/11/21
- Re: [qemu-s390x] [RFC PATCH 1/1] s390x/css: unresrict cssids, Halil Pasic, 2017/11/21
- Re: [qemu-s390x] [RFC PATCH 1/1] s390x/css: unresrict cssids, Cornelia Huck, 2017/11/22
- Re: [qemu-s390x] [RFC PATCH 1/1] s390x/css: unresrict cssids, Boris Fiuczynski, 2017/11/22
- Re: [qemu-s390x] [RFC PATCH 1/1] s390x/css: unresrict cssids,
Cornelia Huck <=
- Re: [qemu-s390x] [RFC PATCH 1/1] s390x/css: unresrict cssids, Halil Pasic, 2017/11/23
- Re: [qemu-s390x] [RFC PATCH 1/1] s390x/css: unresrict cssids, Cornelia Huck, 2017/11/24
- Re: [qemu-s390x] [Qemu-devel] [RFC PATCH 1/1] s390x/css: unresrict cssids, Christian Borntraeger, 2017/11/24
- Re: [qemu-s390x] [Qemu-devel] [RFC PATCH 1/1] s390x/css: unresrict cssids, Cornelia Huck, 2017/11/24
- Re: [qemu-s390x] [Qemu-devel] [RFC PATCH 1/1] s390x/css: unresrict cssids, Christian Borntraeger, 2017/11/24
- Re: [qemu-s390x] [Qemu-devel] [RFC PATCH 1/1] s390x/css: unresrict cssids, Halil Pasic, 2017/11/24
- Re: [qemu-s390x] [Qemu-devel] [RFC PATCH 1/1] s390x/css: unresrict cssids, Cornelia Huck, 2017/11/24
- Re: [qemu-s390x] [Qemu-devel] [RFC PATCH 1/1] s390x/css: unresrict cssids, Halil Pasic, 2017/11/24
- Re: [qemu-s390x] [Qemu-devel] [RFC PATCH 1/1] s390x/css: unresrict cssids, Dong Jia Shi, 2017/11/26
- Re: [qemu-s390x] [Qemu-devel] [RFC PATCH 1/1] s390x/css: unresrict cssids, Cornelia Huck, 2017/11/27