[Top][All Lists]

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

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

From: Cornelia Huck
Subject: Re: [Qemu-devel] [RFC PATCH 1/1] s390x/css: unresrict cssids
Date: Mon, 27 Nov 2017 13:56:24 +0100

On Fri, 24 Nov 2017 17:39:04 +0100
Halil Pasic <address@hidden> wrote:

> On 11/24/2017 05:15 PM, Cornelia Huck wrote:
> >>> In theory this should work. 
> >>>
> >>> In reality it seems more complicated. A per-device property is easy and 
> >>> can be
> >>> inspected on the command line (e.g. -device virtio-blk-ccw,help), while a 
> >>> new 
> >>> machine property would require to change the qemu help output and 
> >>> qemu-options 
> >>> file (which makes it visible for all architectures).    
> >> And then we have the fun of describing, that this property is weird, and 
> >> can
> >> not be set, and it's value does not matter.  
> > Well, that's the case for both, no?  
> I don't think we have to document _device_ properites in qemu-options.hx
> I don't see any documented neither for virtio-ccw nor for vfio-ccw. The
> machine properties, on the contrary, are documented in this file.

But not having to describe it does not make it any less weird.

> > 
> > (Unless we simply make this a "default cssid" prop after all - then it
> > would be more than just a simple indication for libvirt...)
> >   
> We are now talking about the "cssid-unrestricted" property. The default
> cssid is not something I would like to do any time soon.

What's so bad about this? As said above, I think it would be much more
useful. If libvirt can detect r/o vs. r/w for properties, we can simply
start out with a r/o variant now...

reply via email to

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