[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Dong Jia Shi
Subject: Re: [Qemu-devel] [RFC PATCH 1/1] s390x/css: unresrict cssids
Date: Mon, 27 Nov 2017 10:20:56 +0800
User-agent: Mutt/1.5.21 (2010-09-15)

* 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

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

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