From: Anthony Liguori <anthony@codemonkey.ws>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: qemu-devel@nongnu.org, agraf@suse.de
Subject: Re: [Qemu-devel] [PATCH 1/2] Allow QEMUMachine to override reset sequencing
Date: Wed, 01 Aug 2012 21:37:39 -0500 [thread overview]
Message-ID: <87vch2nhn0.fsf@codemonkey.ws> (raw)
In-Reply-To: <1343873409-8571-2-git-send-email-david@gibson.dropbear.id.au>
David Gibson <david@gibson.dropbear.id.au> writes:
> At present the 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 they run is not controlled by the board
> logic.
Let's be careful here in referring to "board logic".
Reset should propagate--there's no argument there. Having all devices
register in a list with no control over how reset is dispatched is
wrong. It's workable because of qdev imposes per-bus reset functions
and typically we have a small number of busses and ordering doesn't
matter.
> This is incorrect: any modern real hardware will generally have some sort
> of reset controller, sometimes a full microcontroller or even service
> processor which will control the order in which components on the board are
> reset.
I think this is true only with a loose definition of "modern", but okay.
I don't think this is the right argument. The machine should serve as
the entry point for reset. What components get reset in what order will
need to be a machine hook for practical purposes (since not everything
will be fully QOMized all at once).
So I think this is the right approach for now.
But all of the DT initialization stuff that is leading to this
discussion in the first place is a gross hack to make a PV architecture
work that took far too many short cuts.
Building a DT in memory representing hardware instead of making things
discoverable is not how hardware works. This sort of stuff is either
(1) hard coded in a firmware/flashrom or (2) built dynamically in
firmware. Let's not pretend like we're doing this because it's needed
for real hardware.
Regards,
Anthony Liguori
> For one specific example, the machine level reset handlers may need to
> re-establish certain things in memory to meet the emulated platform's
> specified entry conditions, before reexecuting the guest software.
> re-establish the correct specified entry conditions for the emulated
> platform. This must happen _after_ resetting peripheral devices, or they
> could still be in the middle of DMA operations which would clobber the new
> memory content. However with the normal ordering of reset hooks, the
> machine is not able to register a hook which will run after the normal
> qdev reset registered by generic code.
>
> This patch allows the machine to take control of the sequence of operations
> during reset, by adding a new reset hook to the QEMUMachine. This hook is
> optional - without it we just use the same reset sequence as always. That
> logic is available in qemu_default_system_reset() to make it easy to
> implement the case of the machine logic just needing to do some things
> either before or after the normal reset.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> ---
> hw/boards.h | 3 +++
> sysemu.h | 1 +
> vl.c | 10 +++++++++-
> 3 files changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/hw/boards.h b/hw/boards.h
> index 59c01d0..f2bfd3e 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(bool report);
> +
> 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 6540c79..f74319b 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_default_system_reset(bool report);
> void qemu_system_reset(bool report);
>
> void qemu_add_exit_notifier(Notifier *notify);
> diff --git a/vl.c b/vl.c
> index 9fea320..ac47a7c 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -1396,7 +1396,7 @@ void qemu_unregister_reset(QEMUResetHandler *func, void *opaque)
> }
> }
>
> -void qemu_system_reset(bool report)
> +void qemu_default_system_reset(bool report)
> {
> QEMUResetEntry *re, *nre;
>
> @@ -1410,6 +1410,14 @@ void qemu_system_reset(bool report)
> cpu_synchronize_all_post_reset();
> }
Not a huge fan of the naming here. How about qemu_devices_reset()?
> +void qemu_system_reset(bool report)
> +{
> + if (current_machine->reset)
> + current_machine->reset(report);
> + else
> + qemu_default_system_reset(report);
> +}
Missing curly braces.
Regards,
Anthony Liguori
> +
> void qemu_system_reset_request(void)
> {
> if (no_reboot) {
> --
> 1.7.10.4
next prev parent reply other threads:[~2012-08-02 2:37 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-02 2:10 [Qemu-devel] [0/2] Allow machine to control ordering of reset David Gibson
2012-08-02 2:10 ` [Qemu-devel] [PATCH 1/2] Allow QEMUMachine to override reset sequencing David Gibson
2012-08-02 2:37 ` Anthony Liguori [this message]
2012-08-02 3:50 ` Benjamin Herrenschmidt
2012-08-02 15:17 ` Paolo Bonzini
2012-08-02 20:46 ` Benjamin Herrenschmidt
2012-08-02 20:58 ` Anthony Liguori
2012-08-03 2:54 ` David Gibson
2012-08-03 3:08 ` David Gibson
2012-08-02 15:00 ` Lluís Vilanova
2012-08-03 2:25 ` David Gibson
2012-08-02 2:10 ` [Qemu-devel] [PATCH 2/2] pseries: Use new hook to correct reset sequence David Gibson
2012-08-02 15:44 ` Andreas Färber
2012-08-02 18:29 ` Anthony Liguori
2012-08-02 18:38 ` Andreas Färber
2012-08-02 19:40 ` Anthony Liguori
2012-08-03 2:37 ` David Gibson
2012-08-03 13:50 ` Anthony Liguori
2012-08-03 13:57 ` Peter Maydell
2012-08-03 14:22 ` Anthony Liguori
2012-08-03 14:35 ` Peter Maydell
2012-08-03 14:51 ` Andreas Färber
2012-08-03 15:01 ` Andreas Färber
2012-08-03 16:21 ` Anthony Liguori
2012-08-07 22:02 ` Benjamin Herrenschmidt
2012-08-07 22:32 ` Andreas Färber
2012-08-08 0:00 ` Anthony Liguori
2012-08-08 7:58 ` Peter Maydell
2012-08-08 8:44 ` David Gibson
2012-08-08 1:45 ` David Gibson
2012-08-08 15:22 ` Andreas Färber
2012-08-09 0:12 ` David Gibson
2012-08-03 2:31 ` David Gibson
2012-08-03 15:13 ` Andreas Färber
2012-08-06 0:31 ` 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=87vch2nhn0.fsf@codemonkey.ws \
--to=anthony@codemonkey.ws \
--cc=agraf@suse.de \
--cc=david@gibson.dropbear.id.au \
--cc=qemu-devel@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 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.