* 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
