* Cornelia Huck <coh...@redhat.com> [2017-11-27 13:58:16 +0100]: > On Mon, 27 Nov 2017 10:20:56 +0800 > Dong Jia Shi <bjsdj...@linux.vnet.ibm.com> wrote: > > > * 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. > > 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