[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: Halil Pasic
Subject: Re: [Qemu-devel] [RFC PATCH 1/1] s390x/css: unresrict cssids
Date: Mon, 27 Nov 2017 15:13:59 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0

On 11/27/2017 02:19 PM, Cornelia Huck wrote:
> On Mon, 27 Nov 2017 14:11:57 +0100
> Halil Pasic <address@hidden> wrote:
>> On 11/27/2017 01:56 PM, Cornelia Huck wrote:
>>> On Fri, 24 Nov 2017 17:39:04 +0100
>>> Halil Pasic <address@hidden> wrote:
>>>> On 11/24/2017 05:15 PM, Cornelia Huck wrote:  
>>>>> (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.  
>>> What's so bad about this? As said above, I think it would be much more
>>> useful. If libvirt can detect r/o vs. r/w for properties, we can simply
>>> start out with a r/o variant now...
>> I'm not sure I understand you. Are you proposing the following:
>> Drop the restriction, but don't indicate this via a read only
>> "cssid-unrestricted" device property but via a "default-css"
>> read only machine property.
>> Libvirt then should know that if "default-css" is present then
>> we don't have this virtual into 0xfe and non virtual into 0xfd
>> restriction any more.
> Yes.

Does this work for you? Technically it's equivalent to having
"cssid-unrestricted" at machine level.

I don't really like the idea of indicating unrestricted via
something mostly unrelated (at least for me it ain't obvious that
having the id of the default css exposed means we got rid of the
limitation.). But I'm tied of discussing this, so I'm willing to


reply via email to

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