qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH RFC 0/2] s390x: cut down on unattached devices


From: Halil Pasic
Subject: Re: [Qemu-devel] [PATCH RFC 0/2] s390x: cut down on unattached devices
Date: Tue, 28 Nov 2017 16:21:20 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0


On 11/28/2017 03:27 PM, Cornelia Huck wrote:
> On Tue, 28 Nov 2017 15:17:38 +0100
> Halil Pasic <address@hidden> wrote:
> 
>> On 11/28/2017 02:46 PM, Cornelia Huck wrote:
>>> info qom-tree shows several devices under unattached that probably
>>> should go somewhere.  
>>
>> I think this was reported by me. See 
>> MID: <address@hidden>
>>
>> I would not mind a Reported-by: Halil Pasic <address@hidden>.
>> Or do you see this differently?
> 
> Apparently I forgot to add it to the first one. Will do.

np

It's just that I've spent quite some time writing that email and
identifying the oddities.

> 
>>
>> If these are bugs. I would prefer commit messages and titles reflecting
>> this fact.
> 
> I don't see this as fixing bugs, more removing oddities.
> 
>>
>> Otherwise at first glance both patches seem sane.
> 
> Can I count this as an ack, or do you plan to do more review?
> 

Yes I was planning to give it another look. And I do already
have questions. Isn't the QOM composition tree API? I mean
let's assume the QMP commands working on this tree are not completely
useless. How is client code (management software) supposed to work,
assumed it can rely on paths of e.g. properties being stable. Just
imagine we had this default-cssid property (for the sake of the
argument, not like we want it) on the css bridge.

Now if the composition tree is API then these can only be bug fixes
(IMHO).

There are also other oddities I've spotted. My idea was to put
this composition tree discussion on hold until the vfio-ccw stuff
is sorted out. I would certainly like to build a better understanding.

Halil

>>
>> Regards,
>> Halil
>>
>>>
>>> The css bridge should attach to the machine, as it has a similar
>>> purpose as e.g. a pci host bridge.
>>>
>>> The autogenerated network devices should be in the same bucket as any
>>> other device; I'm just not sure about the way I went about it.
>>>
>>> The zpci devices are still problematic: I don't have a good idea where
>>> they should show up.
>>>
>>> Remaining in the unattached container are the sysbus, memory regions
>>> and cpus.
>>>
>>> Cornelia Huck (2):
>>>   s390x/css: attach css bridge
>>>   s390x: attach autogenerated nics
>>>
>>>  hw/s390x/css-bridge.c      | 2 ++
>>>  hw/s390x/s390-virtio-ccw.c | 2 ++
>>>  2 files changed, 4 insertions(+)
>>>   
>>
> 
> 




reply via email to

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