qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: David Gibson <david@gibson.dropbear.id.au>
To: agraf@suse.de
Cc: qemu-ppc@nongnu.org, qemu-devel@nongnu.org, paulus@samba.org,
	David Gibson <david@gibson.dropbear.id.au>
Subject: [Qemu-devel] [PATCH 1/7] Allow QEMUMachine to override reset sequencing
Date: Wed, 15 Aug 2012 14:33:42 +1000	[thread overview]
Message-ID: <1345005228-4380-2-git-send-email-david@gibson.dropbear.id.au> (raw)
In-Reply-To: <1345005228-4380-1-git-send-email-david@gibson.dropbear.id.au>

qemu_system_reset() function always performs the same basic actions on
all machines.  This includes running all the reset handler hooks,
however the order in which these will run is not always easily predictable.

This patch splits the core of qemu_system_reset() - the invocation of
the reset handlers - out into a new qemu_devices_reset() function.
qemu_system_reset() will usually call qemu_devices_reset(), but that
can be now overriden by a new reset method in the QEMUMachine
structure.

Individual machines can use this reset method, if necessary, to
perform any extra, machine specific initializations which have to
occur before or after the bulk of the reset handlers.  It's expected
that the method will call qemu_devices_reset() at some point, but if
the machine has really strange ordering requirements between devices
resets it could even override that with it's own reset sequence (with
great care, obviously).

For a specific example of when this might be needed: a number of
machines (but not PC) load images specified with -kernel or -initrd
directly into the machine RAM before booting the guest.  This mostly
works at the moment, but to make this actually safe requires that this
load occurs after peripheral devices are reset - otherwise they could
have active DMAs in progress which would clobber the in memory images.
Some machines (notably pseries) also have other entry conditions which
need to be set up as the last thing before executing in guest space -
some of this could be considered "emulated firmware" in the sense that
the actions of the firmware are emulated directly by qemu rather than
by executing a firmware image within the guest.  When the platform's
firmware to OS interface is sufficiently well specified, this saves
time both in implementing the "firmware" and executing it.

Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
 hw/boards.h |    3 +++
 sysemu.h    |    1 +
 vl.c        |   11 ++++++++++-
 3 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/hw/boards.h b/hw/boards.h
index 59c01d0..a2e0a54 100644
--- a/hw/boards.h
+++ b/hw/boards.h
@@ -12,11 +12,14 @@ typedef void QEMUMachineInitFunc(ram_addr_t ram_size,
                                  const char *initrd_filename,
                                  const char *cpu_model);
 
+typedef void QEMUMachineResetFunc(void);
+
 typedef struct QEMUMachine {
     const char *name;
     const char *alias;
     const char *desc;
     QEMUMachineInitFunc *init;
+    QEMUMachineResetFunc *reset;
     int use_scsi;
     int max_cpus;
     unsigned int no_serial:1,
diff --git a/sysemu.h b/sysemu.h
index 4669348..65552ac 100644
--- a/sysemu.h
+++ b/sysemu.h
@@ -62,6 +62,7 @@ int qemu_powerdown_requested(void);
 void qemu_system_killed(int signal, pid_t pid);
 void qemu_kill_report(void);
 extern qemu_irq qemu_system_powerdown;
+void qemu_devices_reset(void);
 void qemu_system_reset(bool report);
 
 void qemu_add_exit_notifier(Notifier *notify);
diff --git a/vl.c b/vl.c
index d01256a..757d84a 100644
--- a/vl.c
+++ b/vl.c
@@ -1439,7 +1439,7 @@ void qemu_unregister_reset(QEMUResetHandler *func, void *opaque)
     }
 }
 
-void qemu_system_reset(bool report)
+void qemu_devices_reset(void)
 {
     QEMUResetEntry *re, *nre;
 
@@ -1447,6 +1447,15 @@ void qemu_system_reset(bool report)
     QTAILQ_FOREACH_SAFE(re, &reset_handlers, entry, nre) {
         re->func(re->opaque);
     }
+}
+
+void qemu_system_reset(bool report)
+{
+    if (current_machine->reset) {
+        current_machine->reset();
+    } else {
+        qemu_devices_reset();
+    }
     if (report) {
         monitor_protocol_event(QEVENT_RESET, NULL);
     }
-- 
1.7.10.4

  reply	other threads:[~2012-08-15  4:34 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-15  4:33 [Qemu-devel] [0/7] pseries: Patches to fix system reset David Gibson
2012-08-15  4:33 ` David Gibson [this message]
2012-08-15  4:33 ` [Qemu-devel] [PATCH 2/7] ppc: Make kvm_arch_put_registers() put *all* the registers David Gibson
2012-08-17 13:58   ` Alexander Graf
2012-08-17 16:24     ` [Qemu-devel] [Qemu-ppc] " David Gibson
2012-08-15  4:33 ` [Qemu-devel] [PATCH 3/7] pseries: Fix and cleanup CPU initialization and reset David Gibson
2012-08-15  4:33 ` [Qemu-devel] [PATCH 4/7] pseries: Use new method to correct reset sequence David Gibson
2012-08-15  4:33 ` [Qemu-devel] [PATCH 5/7] pseries: Add support for new KVM hash table control call David Gibson
2012-08-15  4:33 ` [Qemu-devel] [PATCH 6/7] pseries: Clear TCE state when resetting PAPR VIO devices David Gibson
2012-08-15  4:33 ` [Qemu-devel] [PATCH 7/7] ppc/pseries: Reset VPA registration on CPU reset David Gibson

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=1345005228-4380-2-git-send-email-david@gibson.dropbear.id.au \
    --to=david@gibson.dropbear.id.au \
    --cc=agraf@suse.de \
    --cc=paulus@samba.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    /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).