qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Jiri Denemark <jdenemar@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: "Kevin Wolf" <kwolf@redhat.com>,
	"Anthony Liguori" <aliguori@us.ibm.com>,
	"Eduardo Habkost" <ehabkost@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"libvir-list@redhat.com" <libvir-list@redhat.com>,
	"Stefan Hajnoczi" <stefanha@gmail.com>,
	qemu-devel@nongnu.org, "Luiz Capitulino" <lcapitulino@redhat.com>,
	laine@redhat.com, "Gerd Hoffmann" <kraxel@redhat.com>,
	"Osier Yang" <jyang@redhat.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Andreas Färber" <afaerber@suse.de>
Subject: Re: [Qemu-devel] [PATCH] qdev: DEVICE_DELETED event
Date: Fri, 8 Mar 2013 10:25:42 +0100	[thread overview]
Message-ID: <20130308092542.GG326424@orkuz.home> (raw)
In-Reply-To: <87boaujmvk.fsf@blackfin.pond.sub.org>

On Fri, Mar 08, 2013 at 09:50:55 +0100, Markus Armbruster wrote:
> Osier Yang <jyang@redhat.com> writes:
> 
> > I'm wondering if it could be long time to wait for the device_del
> > completes (AFAIK from previous bugs, it can be, though it should be
> > fine for most of the cases). If it's too long, it will be a problem
> > for management, because it looks like hanging. We can have a timeout
> > for the device_del in libvirt, but the problem is the device_del
> > can be still in progress by qemu, which could cause the inconsistency.
> > Unless qemu has some command to cancel the device_del.
> 
> I'm afraid cancelling isn't possible, at least not for PCI.

I don't think we need anything like that. We just need the device
deletion API to return immediately without actually removing stuff from
domain definition (unless the device was really removed fast enough,
e.g., USB devices are removed before device_del returns) and then remove
the device from domain definition when we get the event from QEMU or
when libvirtd reconnects to a domain and sees a particular device is no
longer present. After all, devices may be removed even if we didn't ask
for it (when the removal is initiated by a guest OS). And we should also
provide similar event for higher level apps.

The question is whether we can make use of our existing API or if we
need to introduce a new one. But that's of little relevance to
qemu-devel I guess.

Jirka

  reply	other threads:[~2013-03-08  9:25 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-06 13:00 [Qemu-devel] [PATCH] qdev: DEVICE_DELETED event Michael S. Tsirkin
2013-03-06 13:57 ` Andreas Färber
2013-03-06 14:13   ` Michael S. Tsirkin
2013-03-07  9:55     ` Markus Armbruster
2013-03-07 10:07       ` Michael S. Tsirkin
2013-03-07 13:11         ` Andreas Färber
2013-03-07 14:14           ` Markus Armbruster
2013-03-07 16:35             ` Michael S. Tsirkin
2013-03-07 17:23               ` Markus Armbruster
2013-03-07 18:12                 ` Michael S. Tsirkin
2013-03-07 19:00                   ` Andreas Färber
2013-03-07 19:15                     ` Michael S. Tsirkin
2013-03-08  7:09                       ` Osier Yang
2013-03-08  8:50                         ` Markus Armbruster
2013-03-08  9:25                           ` Jiri Denemark [this message]
2013-03-08 10:37                             ` Osier Yang
2013-03-08 10:56                           ` Osier Yang
2013-03-08 11:58                             ` Markus Armbruster
2013-03-07 20:18                   ` Markus Armbruster
2013-03-07 20:29                     ` Michael S. Tsirkin
2013-03-06 14:44 ` Eric Blake
2013-03-06 14:50   ` Michael S. Tsirkin
2013-03-06 14:52   ` Paolo Bonzini
2013-03-06 15:41     ` Eric Blake
2013-03-07  9:38       ` Markus Armbruster

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=20130308092542.GG326424@orkuz.home \
    --to=jdenemar@redhat.com \
    --cc=afaerber@suse.de \
    --cc=aliguori@us.ibm.com \
    --cc=armbru@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=jyang@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=laine@redhat.com \
    --cc=lcapitulino@redhat.com \
    --cc=libvir-list@redhat.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@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 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).