* Halil Pasic <pa...@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.

> > 
> > (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.

-- 
Dong Jia Shi


Reply via email to