qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Tang Chen <tangchen@cn.fujitsu.com>
To: qemu-devel@nongnu.org, imammedo@redhat.com, mst@redhat.com,
	pbonzini@redhat.com
Cc: hutao@cn.fujitsu.com, isimatu.yasuaki@jp.fujitsu.com,
	zhugh.fnst@cn.fujitsu.com, tangchen@cn.fujitsu.com
Subject: [Qemu-devel] [RFC PATCH v1 3/4] Introduce wait condition to catch guest OS memory hotplug error.
Date: Wed, 27 Aug 2014 16:09:47 +0800	[thread overview]
Message-ID: <1409126988-22287-4-git-send-email-tangchen@cn.fujitsu.com> (raw)
In-Reply-To: <1409126988-22287-1-git-send-email-tangchen@cn.fujitsu.com>

When acpi_memory_plug_cb() sends a SCI to guest OS, vcpu thread will handle it.
And QEmu thread will return, who is not able to catch the error if guest OS
failed to handle the SCI.

Of course, if guest OS failed to handle SCI, it will give error messages. But
QEmu will not output anything.

Furthermore, if QEmu cannot catch these errors, applications based on QEmu,
like Libvirt, will also not able to catch them. This could be trouble to end users.

This patch introduces a condition variable named qemu_cond_memhp. QEmu will wait
on qemu_cond_memhp after sending SCI, and vcpu thread will signal QEmu when OST
status is written into ACPI register. This is used by the following patch.

Signed-off-by: Tang Chen <tangchen@cn.fujitsu.com>
---
 hw/acpi/memory_hotplug.c | 38 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 38 insertions(+)

diff --git a/hw/acpi/memory_hotplug.c b/hw/acpi/memory_hotplug.c
index fddb0fd..38d9654 100644
--- a/hw/acpi/memory_hotplug.c
+++ b/hw/acpi/memory_hotplug.c
@@ -4,6 +4,12 @@
 #include "hw/boards.h"
 #include "trace.h"
 #include "qapi-event.h"
+#include "qemu/thread.h"
+#include "qemu/main-loop.h"
+
+/* _OST called by guest OS */
+static QemuCond qemu_memhp_cond;
+static QemuMutex qemu_memhp_mutex;
 
 static ACPIOSTInfo *acpi_memory_device_status(int slot, MemStatus *mdev)
 {
@@ -93,6 +99,8 @@ static void acpi_handle_insert(MemStatus *mdev)
     case ACPI_UNRECOGNIZED_NOTIFY:
     case ACPI_INSERT_DRIVER_LOAD_FAILURE:
     case ACPI_INSERT_NOT_SUPPORTED:
+        /* Signal QEmu to continue.*/
+        qemu_cond_signal(&qemu_memhp_cond);
     case ACPI_INSERT_IN_PROGRESS:
     default:
         break;
@@ -106,6 +114,9 @@ static void acpi_handle_eject(MemStatus *mdev)
         object_unparent(OBJECT(mdev->dimm));
         mdev->is_removing = false;
         mdev->dimm = NULL;
+
+        /* Signal QEmu to continue.*/
+        qemu_cond_signal(&qemu_memhp_cond);
         break;
     case ACPI_EJECT_IN_PROGRESS:
         /* For ejection triggered by hardware (device_del command),
@@ -126,6 +137,9 @@ static void acpi_handle_eject(MemStatus *mdev)
     case ACPI_EJECT_DEPENDENCY_BUSY:
         mdev->is_removing = false;
         mdev->is_enabled = true;
+
+        /* Signal QEmu to catch errors. */
+        qemu_cond_signal(&qemu_memhp_cond);
         break;
     default:
         break;
@@ -181,12 +195,16 @@ static void acpi_memory_hotplug_write(void *opaque, hwaddr addr, uint64_t data,
             /* TODO: handle device remove OST event */
             break;
         }
+        qemu_mutex_lock(&qemu_memhp_mutex);
         mdev->ost_event = data;
+        qemu_mutex_unlock(&qemu_memhp_mutex);
         trace_mhp_acpi_write_ost_ev(mem_st->selector, mdev->ost_event);
         break;
     case 0x8: /* _OST status */
         mdev = &mem_st->devs[mem_st->selector];
+        qemu_mutex_lock(&qemu_memhp_mutex);
         mdev->ost_status = data;
+        qemu_mutex_unlock(&qemu_memhp_mutex);
         trace_mhp_acpi_write_ost_status(mem_st->selector, mdev->ost_status);
 
         info = acpi_memory_device_status(mem_st->selector, mdev);
@@ -234,6 +252,9 @@ void acpi_memory_hotplug_init(MemoryRegion *as, Object *owner,
     memory_region_init_io(&state->io, owner, &acpi_memory_hotplug_ops, state,
                           "acpi-mem-hotplug", ACPI_MEMORY_HOTPLUG_IO_LEN);
     memory_region_add_subregion(as, ACPI_MEMORY_HOTPLUG_BASE, &state->io);
+
+    qemu_cond_init(&qemu_memhp_cond);
+    qemu_mutex_init(&qemu_memhp_mutex);
 }
 
 void acpi_memory_plug_cb(ACPIREGS *ar, qemu_irq irq, MemHotplugState *mem_st,
@@ -265,6 +286,23 @@ void acpi_memory_plug_cb(ACPIREGS *ar, qemu_irq irq, MemHotplugState *mem_st,
     /* do ACPI magic */
     ar->gpe.sts[0] |= ACPI_MEMORY_HOTPLUG_STATUS;
     acpi_update_sci(ar, irq);
+
+    /* When SCI is sent, wait for guest OS handling and catch errors.
+     *
+     * QEmu locked all the iothreads before handling monitor command in
+     * os_host_main_loop_wait(). Unlock them so that vcpu threads are able
+     * to handle ACPI register writing requests from guest OS. And relock
+     * them after we are signaled.
+     */
+    qemu_mutex_unlock_iothread();
+    qemu_mutex_lock(&qemu_memhp_mutex);
+    /* qemu_cond_wait() will release qemu_memhp_mutex and wait,
+     * and will relock it when signaled.
+     */
+    qemu_cond_wait(&qemu_memhp_cond, &qemu_memhp_mutex);
+    qemu_mutex_unlock(&qemu_memhp_mutex);
+    qemu_mutex_lock_iothread();
+
     return;
 }
 
-- 
1.8.4.2

  parent reply	other threads:[~2014-08-27  8:09 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-27  8:09 [Qemu-devel] [RFC PATCH v1 0/4] Handle memory hotplug errors from guest OS Tang Chen
2014-08-27  8:09 ` [Qemu-devel] [RFC PATCH v1 1/4] Use macro to define ACPI notification event Tang Chen
2014-08-27  8:09 ` [Qemu-devel] [RFC PATCH v1 2/4] Add event handling for memory device insertion Tang Chen
2014-08-27  8:09 ` Tang Chen [this message]
2014-08-27  8:09 ` [Qemu-devel] [RFC PATCH v1 4/4] Handle memory hotplug error from guest OS in QEmu Tang Chen
2014-08-27  8:14 ` [Qemu-devel] [RFC PATCH v1 0/4] Handle memory hotplug errors from guest OS tangchen
2014-09-03  9:05   ` tangchen

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=1409126988-22287-4-git-send-email-tangchen@cn.fujitsu.com \
    --to=tangchen@cn.fujitsu.com \
    --cc=hutao@cn.fujitsu.com \
    --cc=imammedo@redhat.com \
    --cc=isimatu.yasuaki@jp.fujitsu.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=zhugh.fnst@cn.fujitsu.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).