From: Halil Pasic <pasic@linux.vnet.ibm.com>
To: Cornelia Huck <cohuck@redhat.com>,
Christian Borntraeger <borntraeger@de.ibm.com>
Cc: qemu-devel@nongnu.org, qemu-s390x@nongnu.org, pmorel@linux.vnet.ibm.com
Subject: Re: [Qemu-devel] [qemu-s390x] [PATCH RFC 2/2] s390x: attach autogenerated nics
Date: Mon, 4 Dec 2017 18:33:24 +0100 [thread overview]
Message-ID: <a3b25300-1ba7-fe2f-c099-f3da6b2157dc@linux.vnet.ibm.com> (raw)
In-Reply-To: <20171204174056.182ec0f0.cohuck@redhat.com>
On 12/04/2017 05:40 PM, Cornelia Huck wrote:
> On Mon, 4 Dec 2017 12:17:06 +0100
> Christian Borntraeger <borntraeger@de.ibm.com> wrote:
>
>> On 11/28/2017 02:46 PM, Cornelia Huck wrote:
>>> The autogenerated nics should be treated as any other device; use
>>> qdev_set_id() to have them show up under peripheral-anon.
>>>
>> I think this is fine, but then I ask myself how x86 does this. So I tried to
>> find out how the pc-q35 machine does this but I somehow failed to understand
>> how they do it. Do you have any clue?
>
> It seems they don't. If you start up a machine with only autogenerated
> devices, you won't find anything under peripheral{-anon}, but several
> devices under unattached.
>
> So, maybe we should change this for everything? Or just leave it alone?
>
> (The css-bridge change is a different thing IMO, it clearly should be
> attached to the machine.)
>
IMHO (try to) change everywhere. The devices are attached to the machine,
and them showing up as unattached is misleading. IMHO we still to have the
'is it API or not' question/problem so we need to be careful.
Another think I was wondering about is ids: there are QMP commands which
designate devices by path and there are commands which designate by id
(and we even have either-or via the same parameter in case of device_del).
Since the paths do not seem to be directly assigned/controlled by the user
([1]] but id's are I would argue that ids are easier to understand and
use. Would generating an id for each auto-generated device be a good idea?
I'm trying to figure out, how the QAPI is supposed to be used, and feel like.
So take my comments with a grain of salt.
[1] One can, but does not have to specify the bus. Libvirt does not seem
to for virtio-ccw devices. And if one were to, the other patch in the
series could break that code.
Halil
>>
>>> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
>>> ---
>>> hw/s390x/s390-virtio-ccw.c | 2 ++
>>> 1 file changed, 2 insertions(+)
>>>
>>> diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
>>> index a23b8aec9f..830bae9d0f 100644
>>> --- a/hw/s390x/s390-virtio-ccw.c
>>> +++ b/hw/s390x/s390-virtio-ccw.c
>>> @@ -35,6 +35,7 @@
>>> #include "cpu_models.h"
>>> #include "qapi/qmp/qerror.h"
>>> #include "hw/nmi.h"
>>> +#include "include/monitor/qdev.h"
>>>
>>> S390CPU *s390_cpu_addr2state(uint16_t cpu_addr)
>>> {
>>> @@ -259,6 +260,7 @@ static void s390_create_virtio_net(BusState *bus, const char *name)
>>>
>>> dev = qdev_create(bus, name);
>>> qdev_set_nic_properties(dev, nd);
>>> + qdev_set_id(dev, NULL);
>>> qdev_init_nofail(dev);
>>> }
>>> }
>>>
>>
>
next prev parent reply other threads:[~2017-12-04 17:33 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-28 13:46 [Qemu-devel] [PATCH RFC 0/2] s390x: cut down on unattached devices Cornelia Huck
2017-11-28 13:46 ` [Qemu-devel] [PATCH RFC 1/2] s390x/css: attach css bridge Cornelia Huck
2017-11-28 14:02 ` Christian Borntraeger
2017-12-08 11:43 ` Cornelia Huck
2017-11-28 13:46 ` [Qemu-devel] [PATCH RFC 2/2] s390x: attach autogenerated nics Cornelia Huck
2017-12-04 11:17 ` [Qemu-devel] [qemu-s390x] " Christian Borntraeger
2017-12-04 16:40 ` Cornelia Huck
2017-12-04 17:33 ` Halil Pasic [this message]
2017-12-04 17:51 ` Cornelia Huck
2017-11-28 14:17 ` [Qemu-devel] [PATCH RFC 0/2] s390x: cut down on unattached devices Halil Pasic
2017-11-28 14:27 ` Cornelia Huck
2017-11-28 15:21 ` Halil Pasic
2017-12-01 14:41 ` Halil Pasic
2017-12-04 9:22 ` Cornelia Huck
2017-12-04 14:47 ` Halil Pasic
2017-12-04 16:51 ` Cornelia Huck
2017-12-04 11:47 ` [Qemu-devel] [qemu-s390x] " David Hildenbrand
2017-12-05 8:59 ` [Qemu-devel] " Bjoern Walk
2017-12-07 16:34 ` Cornelia Huck
2017-12-07 17:01 ` Halil Pasic
2017-12-07 17:06 ` Cornelia Huck
2017-12-07 17:15 ` Halil Pasic
2017-12-08 11:42 ` Cornelia Huck
2017-12-08 12:14 ` Halil Pasic
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a3b25300-1ba7-fe2f-c099-f3da6b2157dc@linux.vnet.ibm.com \
--to=pasic@linux.vnet.ibm.com \
--cc=borntraeger@de.ibm.com \
--cc=cohuck@redhat.com \
--cc=pmorel@linux.vnet.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-s390x@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).