qemu-devel
[Top][All Lists]
Advanced

[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:58:16 +0100

On Mon, 27 Nov 2017 10:20:56 +0800
Dong Jia Shi <address@hidden> wrote:

> * Halil Pasic <address@hidden> [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).



reply via email to

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