From: "Andreas Färber" <afaerber@suse.de>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: aliguori@us.ibm.com, qemu-ppc@nongnu.org, agraf@suse.de,
qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] Allow QEMUMachine to override reset sequencing
Date: Thu, 09 Aug 2012 17:47:28 +0200 [thread overview]
Message-ID: <5023DB90.2040206@suse.de> (raw)
In-Reply-To: <1344321711-15782-1-git-send-email-david@gibson.dropbear.id.au>
Am 07.08.2012 08:41, schrieb David Gibson:
> 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>
Reviewed-by: Andreas Färber <afaerber@suse.de>
I'll put together a follow-up to show what I meant in the v1 thread.
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
prev parent reply other threads:[~2012-08-09 15:47 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-07 6:41 [Qemu-devel] [PATCH] Allow QEMUMachine to override reset sequencing David Gibson
2012-08-07 21:53 ` Benjamin Herrenschmidt
2012-08-09 15:47 ` Andreas Färber [this message]
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=5023DB90.2040206@suse.de \
--to=afaerber@suse.de \
--cc=agraf@suse.de \
--cc=aliguori@us.ibm.com \
--cc=david@gibson.dropbear.id.au \
--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 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.