All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eduardo Habkost <ehabkost@redhat.com>
To: Thomas Huth <thuth@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	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:59:44 -0300	[thread overview]
Message-ID: <20170925175944.GD3030@localhost.localdomain> (raw)
In-Reply-To: <59e890ab-45e4-fe8a-a8de-3c441de19080@redhat.com>

On Mon, Sep 25, 2017 at 07:42:13PM +0200, Thomas Huth wrote:
> On 25.09.2017 17:26, 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.
> 
> Yes, I know ... I'm just wondering whether the virtio-xxx-device devices
> should be non-user_creatable on the non-ARM targets, since they
> apparently can't be used with "-device" there...?

I wouldn't like to make DeviceClass fields depend on the target.
Being user-creatable doesn't mean they will work on all machines,
anyway.  If user/management need more specific info, they need
something like the query-device-slots command I've proposed some
time ago.

> 
> > 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.
> 
> Yes, if Eduardo's idea to move the test to qmp_device_add() does not
> work out (I'll try that next), your suggestion is certainly the best
> thing we can do right now.

I think it would work, but we would lose the feature Peter
mentions below:

> 
> > 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).
> 
> Ok ... by the way, does anybody know more devices like
> virtio-xxx-device, i.e. devices that are indirectly plugged when adding
> other devices?

"make check" found a few candidates:
https://travis-ci.org/ehabkost/qemu/jobs/278743999

  Initialization of device dpcd failed: Device 'dpcd' does not support hotplugging
[...]
  Initialization of device nand failed: Device 'nand' does not support hotplugging

Finding the full list of devices that can be instantiated
internally at hotplug-time sounds tricky.

-- 
Eduardo

  parent reply	other threads:[~2017-09-25 18:00 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 [this message]
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
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=20170925175944.GD3030@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.