All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eduardo Habkost <ehabkost@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Thomas Huth <thuth@redhat.com>,
	Igor Mammedov <imammedo@redhat.com>,
	Cornelia Huck <cohuck@redhat.com>,
	QEMU Developers <qemu-devel@nongnu.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Xiao Guangrong <xiaoguangrong.eric@gmail.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Marcel Apfelbaum <marcel@redhat.com>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	Gerd Hoffmann <kraxel@redhat.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Anthony Perard <anthony.perard@citrix.com>,
	David Hildenbrand <david@redhat.com>,
	David Gibson <david@gibson.dropbear.id.au>,
	Bharata B Rao <bharata@linux.vnet.ibm.com>,
	Amit Shah <amit@kernel.org>
Subject: Re: [Qemu-devel] [PATCH v2] qdev: Mark devices as non-hotpluggable by default
Date: Mon, 25 Sep 2017 14:48:19 -0300	[thread overview]
Message-ID: <20170925174819.GB3030@localhost.localdomain> (raw)
In-Reply-To: <CAFEAcA-kmSkjhM0f+Ti7nY1_AuDm1pPcYHNGn50fes20YvOeBg@mail.gmail.com>

On Mon, Sep 25, 2017 at 04:26:44PM +0100, Peter Maydell wrote:
> On 25 September 2017 at 16:19, Thomas Huth <thuth@redhat.com> wrote:
> > Not sure whether this works for the virtio-xxx-device devices,
> > though, since they are marked as user_creatable = true currently...
> 
> That's deliberate -- for the arm boards with virtio-mmio
> the board creates a bunch of virtio-mmio transports and the
> virtio-foo-device can be user created to plug into those.

Do they support device_add virtio-xxx-device, though?  If they
don't, should we report it as hotpluggable on a future QMP
query-device-type command?

> 
> If overall trying to do the 'right thing' is tricky here
> then perhaps we can start by flipping the default to
> not-hotpluggable and marking some devices hotpluggable
> that in theory shouldn't be with a comment about why.

Finding the full list of those devices is the tricky part.

> 
> Incidentally I think there's still some advantage in the
> "created as part of some other device" devices having
> to be explicitly marked hotpluggable, because those
> devices do still need some specific code in them to
> handle it (ie code to release the resources that are
> created in the device's realize method).

I agree this is still useful.

I was trying represent something different: I was looking for a
flag meaning "supports device_add", while the current meaning is
"supports late instantiation".

On all devices, device_add support requires late instantiation.
On most user-creatable devices, late instantiation support
implies device_add support (virtio-*-device is the only
exception).

This confusion can be solved by documenting
DeviceClass::hotpluggable as "may support device_add, as long as
the machine and bus lets you do it", so there's no harm in
setting it to true on virtio-*-device.

This won't allow us to automatically tell if a device can be
safely instantiated without a hotplug controller, though.

-- 
Eduardo

  parent reply	other threads:[~2017-09-25 17:49 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-22  9:16 [Qemu-devel] [PATCH v2] qdev: Mark devices as non-hotpluggable by default Thomas Huth
2017-09-22 10:13 ` David Gibson
2017-09-25 10:13 ` Marcel Apfelbaum
2017-09-25 11:53 ` Cornelia Huck
2017-09-25 13:31   ` Eduardo Habkost
2017-09-25 13:46     ` Igor Mammedov
2017-09-25 14:34       ` Eduardo Habkost
2017-09-25 15:19         ` Thomas Huth
2017-09-25 15:26           ` Peter Maydell
2017-09-25 17:42             ` Thomas Huth
2017-09-25 17:45               ` Peter Maydell
2017-09-25 17:51                 ` Eduardo Habkost
2017-09-25 18:02                   ` Peter Maydell
2017-09-25 18:20                     ` Eduardo Habkost
2017-09-25 18:46                       ` Peter Maydell
2017-09-25 17:59               ` Eduardo Habkost
2017-09-25 18:05                 ` Peter Maydell
2017-09-25 18:09                   ` Eduardo Habkost
2017-09-26  2:59                   ` Eduardo Habkost
2017-09-26  3:29                     ` Thomas Huth
2017-09-26 16:11                     ` Peter Maydell
2017-09-26 17:27                 ` Thomas Huth
2017-09-26 18:00                   ` Peter Maydell
2017-09-25 17:48             ` Eduardo Habkost [this message]
2017-09-26  5:26 ` Bharata B Rao
2017-09-26 10:20   ` Thomas Huth

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=20170925174819.GB3030@localhost.localdomain \
    --to=ehabkost@redhat.com \
    --cc=amit@kernel.org \
    --cc=anthony.perard@citrix.com \
    --cc=bharata@linux.vnet.ibm.com \
    --cc=borntraeger@de.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=david@redhat.com \
    --cc=imammedo@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=marcel@redhat.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=sstabellini@kernel.org \
    --cc=thuth@redhat.com \
    --cc=xiaoguangrong.eric@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.