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

[Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com>]

* Cornelia Huck <cohuck@redhat.com> [2017-11-27 13:58:16 +0100]:

> On Mon, 27 Nov 2017 10:20:56 +0800
> Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com> wrote:
> 
> > * Halil Pasic <pasic@linux.vnet.ibm.com> [2017-11-24 17:39:04 +0100]:
> > 
> > > 
> > > 
> > > 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.  
> > Is it sane and possible to reuse the existing s390-squash-mcss property
> > to achieve the goal?  I mean, when it is false (which is the default
> > value), can we treat it as "we are allowed to put devices everywhere"?
> > Then we'd have the way to use a property of the -M to tell libvirt that
> > devices can be everywhere?
> > 
> > However then we can not drop it completely I guess, since Libvirt will
> > depends on it. But we can ignore the operation of setting it's value to
> > true.
> 
> I don't think we should reuse it, as it would have rather confusing
> semantics (which can't be easily sorted out unless you check for the
> qemu version).
> 
Right. This is something that I missed. So please ignore my noise.

-- 
Dong Jia Shi