From: Amit Shah <amit.shah@redhat.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
agl@us.ibm.com, qemu list <qemu-devel@nongnu.org>,
Juan Quintela <quintela@redhat.com>
Subject: Re: [Qemu-devel] [PATCH V2] balloon: Don't try fetching info if machine is stopped
Date: Thu, 26 Aug 2010 11:35:13 +0530 [thread overview]
Message-ID: <20100826060513.GF18351@amit-laptop.redhat.com> (raw)
In-Reply-To: <4C719C7E.6030606@codemonkey.ws>
On (Sun) Aug 22 2010 [16:54:06], Anthony Liguori wrote:
> On 08/19/2010 07:48 PM, Amit Shah wrote:
> >If the machine is stopped and 'info balloon' is invoked, the monitor
> >process just hangs waiting for info from the guest. Return the most
> >recent balloon data in that case.
> >
> >See https://bugzilla.redhat.com/show_bug.cgi?id=623903
> >
> >Reported-by:<lihuang@redhat.com>
> >Signed-off-by: Amit Shah<amit.shah@redhat.com>
>
> !vm_running is just a special case of an unresponsive guest. Even
> if the guest was running, if it was oops'd and the administrator
> didn't know, you would have the same issue.
>
> I'd suggest using a timeout based on rt_clock. If the stats request
> times out, print an appropriate message to the user.
This is what I have currently. It would need some timer handling in the
save/load case as well, right?
Amit
>From efe4a36423d7dec1aa9b142ac14c82c2dc80abe4 Mon Sep 17 00:00:00 2001
Message-Id: <efe4a36423d7dec1aa9b142ac14c82c2dc80abe4.1282802628.git.amit.shah@redhat.com>
From: Amit Shah <amit.shah@redhat.com>
Date: Thu, 26 Aug 2010 11:17:14 +0530
Subject: [PATCH] balloon: Don't try fetching info if guest is unresponsive
If the guest is unresponsive and 'info balloon' is invoked, the monitor
process just hangs waiting for info from the guest. Return the most
recent balloon data in that case.
A new timer is added, which on expiry, just presents the old data to the
monitor callback functions.
See https://bugzilla.redhat.com/show_bug.cgi?id=623903
Reported-by: <lihuang@redhat.com>
Signed-off-by: Amit Shah <amit.shah@redhat.com>
---
hw/virtio-balloon.c | 11 +++++++++++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/hw/virtio-balloon.c b/hw/virtio-balloon.c
index 9fe3886..1ec03b3 100644
--- a/hw/virtio-balloon.c
+++ b/hw/virtio-balloon.c
@@ -40,6 +40,7 @@ typedef struct VirtIOBalloon
size_t stats_vq_offset;
MonitorCompletion *stats_callback;
void *stats_opaque_callback_data;
+ QEMUTimer *timer;
} VirtIOBalloon;
static VirtIOBalloon *to_virtio_balloon(VirtIODevice *vdev)
@@ -137,6 +138,11 @@ static void complete_stats_request(VirtIOBalloon *vb)
vb->stats_callback = NULL;
}
+static void stats_timer_expired(void *opaque)
+{
+ complete_stats_request(opaque);
+}
+
static void virtio_balloon_receive_stats(VirtIODevice *vdev, VirtQueue *vq)
{
VirtIOBalloon *s = DO_UPCAST(VirtIOBalloon, vdev, vdev);
@@ -148,6 +154,8 @@ static void virtio_balloon_receive_stats(VirtIODevice *vdev, VirtQueue *vq)
return;
}
+ qemu_del_timer(s->timer);
+
/* Initialize the stats to get rid of any stale values. This is only
* needed to handle the case where a guest supports fewer stats than it
* used to (ie. it has booted into an old kernel).
@@ -215,6 +223,7 @@ static void virtio_balloon_to_target(void *opaque, ram_addr_t target,
dev->stats_callback = cb;
dev->stats_opaque_callback_data = cb_data;
if (dev->vdev.guest_features & (1 << VIRTIO_BALLOON_F_STATS_VQ)) {
+ qemu_mod_timer(dev->timer, qemu_get_clock(rt_clock) + 5000);
virtqueue_push(dev->svq, &dev->stats_vq_elem, dev->stats_vq_offset);
virtio_notify(&dev->vdev, dev->svq);
} else {
@@ -267,6 +276,8 @@ VirtIODevice *virtio_balloon_init(DeviceState *dev)
s->dvq = virtio_add_queue(&s->vdev, 128, virtio_balloon_handle_output);
s->svq = virtio_add_queue(&s->vdev, 128, virtio_balloon_receive_stats);
+ s->timer = qemu_new_timer(rt_clock, stats_timer_expired, s);
+
reset_stats(s);
qemu_add_balloon_handler(virtio_balloon_to_target, s);
--
1.7.2.2
next prev parent reply other threads:[~2010-08-26 6:05 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-20 0:48 [Qemu-devel] [PATCH V2] balloon: Don't try fetching info if machine is stopped Amit Shah
2010-08-20 10:13 ` [Qemu-devel] " Paolo Bonzini
2010-08-20 12:01 ` [Qemu-devel] " Amit Shah
2010-08-22 21:54 ` Anthony Liguori
2010-08-23 9:24 ` Daniel P. Berrange
2010-08-26 5:25 ` Amit Shah
2010-08-26 6:05 ` Amit Shah [this message]
2010-08-26 8:05 ` Paolo Bonzini
2010-08-26 8:14 ` Daniel P. Berrange
2010-08-26 13:22 ` Anthony Liguori
2010-08-26 8:17 ` Amit Shah
2010-08-26 8:19 ` Paolo Bonzini
2010-08-26 8:28 ` Daniel P. Berrange
2010-08-26 12:57 ` Luiz Capitulino
2010-08-26 13:30 ` Paolo Bonzini
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=20100826060513.GF18351@amit-laptop.redhat.com \
--to=amit.shah@redhat.com \
--cc=agl@us.ibm.com \
--cc=anthony@codemonkey.ws \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.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).