All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frederic Konrad <fred.konrad@greensocs.com>
To: Jesse Larrew <jlarrew@linux.vnet.ibm.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
	"Stefan Hajnoczi" <stefanha@gmail.com>,
	jasowang@redhat.com, qemu-devel@nongnu.org,
	mdroth@linux.vnet.ibm.com,
	"Anthony Liguori" <anthony@codemonkey.ws>,
	"Andreas Färber" <afaerber@suse.de>
Subject: Re: [Qemu-devel] [PATCH 1/3] virtio: add bus_plugged() callback to VirtioDeviceClass
Date: Wed, 05 Jun 2013 17:18:35 +0200	[thread overview]
Message-ID: <51AF56CB.4030002@greensocs.com> (raw)
In-Reply-To: <51AE47D3.6080709@linux.vnet.ibm.com>

On 04/06/2013 22:02, Jesse Larrew wrote:
> On 06/04/2013 12:35 PM, Andreas Färber wrote:
>> Hi,
>>
> Hi Andreas!
>
> Thanks for the review. :)
>
>> Am 04.06.2013 18:22, schrieb Jesse Larrew:
>>> Virtio devices are initialized prior to plugging them into a bus. However,
>>> other initializations (such as host_features) don't occur until after the
>>> device is plugged into the bus. If a device needs to modify it's
>>> configuration based on host_features, then it needs to be notified when the
>>> bus is attached and host_features is available for use.
>>>
>>> This patch extends struct VirtioDeviceClass to add a bus_plugged() method.
>>> If implemented by a device, it will be called after the device is attached
>>> to a bus.
>>>
>>> Signed-off-by: Jesse Larrew <jlarrew@linux.vnet.ibm.com>
>> I think this is backwards...
>>
>> First of all, why is host_features not available before?
>>
>> A hook on the bus makes sense because it allows central handling for any
>> devices on that bus.
>> However for a device, first TypeInfo::instance_init is run, then
>> qdev_set_parent_bus() connects the bus and finally DeviceClass::realize
>> is run - and we want to postpone realize further in the future.
>>
> Yes! This would do perfectly.
>
>> So why can't this be in VirtioDevice's or VirtIONet's realize method? At
>> realize time we should definitely be on the bus in this case. I.e.,
>> create vdev->config only after we know how large it needs to be rather
>> than creating and later resizing it, which might fail.
>>
> It appears that virtio hasn't been completely converted to use realize() yet.
> Currently, device_realize() in virtio.c simply calls virtio_device_init(),
> which looks like this:
>
> static int virtio_device_init(DeviceState *qdev)
> {
>      VirtIODevice *vdev = VIRTIO_DEVICE(qdev);
>      VirtioDeviceClass *k = VIRTIO_DEVICE_GET_CLASS(qdev);
>      assert(k->init != NULL);
>      if (k->init(vdev) < 0) {
>          return -1;
>      }
>      virtio_bus_plug_device(vdev);
>      return 0;
> }
>
> VirtioDeviceClass::init() calls virtio_init(), which allocates the config
> struct. Then virtio_bus_plug_device() is called to attach the bus (and to
> populate host_features). I wonder if it's safe to call
> virtio_bus_plug_device() sooner...

Hi Jesse,
Maybe with little change.

virtio_pci_device_plugged need the virtio-device to be initialized.

Fred
>
>> Regards,
>> Andreas
>>
> Sincerely,
>
> Jesse Larrew
> Software Engineer, KVM Team
> IBM Linux Technology Center
> Phone: (512) 973-2052 (T/L: 363-2052)
> jlarrew@linux.vnet.ibm.com
>

  reply	other threads:[~2013-06-05 15:18 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-04 16:22 [Qemu-devel] [PATCH 0/3] Notify devices when a bus is attached Jesse Larrew
2013-06-04 16:22 ` [Qemu-devel] [PATCH 1/3] virtio: add bus_plugged() callback to VirtioDeviceClass Jesse Larrew
2013-06-04 17:35   ` Andreas Färber
2013-06-04 20:02     ` Jesse Larrew
2013-06-05 15:18       ` Frederic Konrad [this message]
2013-06-05 15:09     ` Frederic Konrad
2013-06-04 16:22 ` [Qemu-devel] [PATCH 2/3] virtio-net: implement bus_plugged() Jesse Larrew
2013-06-04 16:22 ` [Qemu-devel] [PATCH 3/3] virtio-net: revert MAC address workaround Jesse Larrew

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=51AF56CB.4030002@greensocs.com \
    --to=fred.konrad@greensocs.com \
    --cc=afaerber@suse.de \
    --cc=anthony@codemonkey.ws \
    --cc=jasowang@redhat.com \
    --cc=jlarrew@linux.vnet.ibm.com \
    --cc=mdroth@linux.vnet.ibm.com \
    --cc=mst@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.