From: "Edgar E. Iglesias" <edgar.iglesias@gmail.com>
To: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
Cc: andreas.faerber@suse.de, qemu-devel@nongnu.org, dantesu@faraday-tech.com
Subject: Re: [Qemu-devel] [RFC PATCH v1 0/7] Reset and Halting modifications + Zynq SMP
Date: Sat, 30 Mar 2013 09:13:15 +0100 [thread overview]
Message-ID: <20130330081315.GC21321@smtp.vpn> (raw)
In-Reply-To: <cover.1362387545.git.peter.crosthwaite@xilinx.com>
On Mon, Mar 04, 2013 at 07:01:32PM +1000, Peter Crosthwaite wrote:
> Hi All. The clock controller module in the Zynq platform has the ability to halt
> and reset arbitrary devices, including the CPU. We use this feature to implement
> SMP Linux - the kernel halts CPU1 then rewrites the vector table to the
> secondary entry point and unhalts.
>
> The clock controller however is reasonable generic, in that in has the ability
> to halt and reset any arbitrary device in the Zynq SoC. The interface for doing
> this is reasonably consistent. So im looking for unified way to halt and reset
> arbitrary devices CPUs included. So given we already have reset() defined on the
> TYPE_DEVICE level, i've added halt as well.
>
> This series is based on v3 of the current qom-cpu queue to pick up the move of
> cpu halt out of the env. From this I attach the cpu::halted bit to the
> Device::(un)halt function.
>
> Next up, CPUs seem to have a different reset path to normal devices. So I have
> trivially hooked up CPU::Reset to Device::Reset. This means that anyone who
> holds a DeviceState pointer to the CPU can reset it properly without actually
> knowing its a CPU.
>
> With the halt API I played with changing an existing device over to use it in
> place of the CPU halted bit (sun4m).
>
> I then finally add SMP support to the Zynq machine, and patch the Zynq SLCR
> (my clock controller) to have DeviceState pointers to the CPUs. device_reset()
> and device_halt() is where the magic happens.
>
> Future work, more devices in Zynq will have halt and reset. My agenda for
> abstracting away the fact that attached device is a CPU is to allow for
> consistent implementation and a single code path for the clock controlled
> devices.
Hi Peter,
I like the approach. As I mentioned in the other thread, the interface
might need to be extended to propagate more info in the future.
IMO, something like this would be useful now.
Cheers,
Edgar
>
>
> Peter A. G. Crosthwaite (3):
> xilinx_zynq: added smp support
> zynq_slcr: Add links to the CPUs
> zynq_slcr: Implement CPU reset and halting
>
> Peter Crosthwaite (4):
> qdev: Define halting API
> qom/cpu.c: Encapsulate cpu halting
> qom/cpu.c: Hook CPU reset up to device reset
> sun4m: Use halting API to halt/unhalt CPUs
>
> hw/qdev-core.h | 17 ++++++++++++++
> hw/qdev.c | 18 ++++++++++++++
> hw/sun4m.c | 24 +++++++++---------
> hw/xilinx_zynq.c | 66 ++++++++++++++++++++++++++++++++++++++++++++---------
> hw/zynq_slcr.c | 30 ++++++++++++++++++++++++
> qom/cpu.c | 22 ++++++++++++++++++
> 6 files changed, 153 insertions(+), 24 deletions(-)
>
>
prev parent reply other threads:[~2013-03-30 8:17 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-04 9:01 [Qemu-devel] [RFC PATCH v1 0/7] Reset and Halting modifications + Zynq SMP Peter Crosthwaite
2013-03-04 9:01 ` [Qemu-devel] [RFC PATCH v1 1/7] qdev: Define halting API Peter Crosthwaite
2013-03-04 9:01 ` [Qemu-devel] [RFC PATCH v1 2/7] qom/cpu.c: Encapsulate cpu halting Peter Crosthwaite
2013-03-30 8:04 ` Edgar E. Iglesias
2013-03-04 9:01 ` [Qemu-devel] [RFC PATCH v1 3/7] qom/cpu.c: Hook CPU reset up to device reset Peter Crosthwaite
2013-03-04 9:01 ` [Qemu-devel] [RFC PATCH v1 4/7] sun4m: Use halting API to halt/unhalt CPUs Peter Crosthwaite
2013-03-04 9:01 ` [Qemu-devel] [RFC PATCH v1 5/7] xilinx_zynq: added smp support Peter Crosthwaite
2013-03-04 9:01 ` [Qemu-devel] [RFC PATCH v1 6/7] zynq_slcr: Add links to the CPUs Peter Crosthwaite
2013-03-04 9:01 ` [Qemu-devel] [RFC PATCH v1 7/7] zynq_slcr: Implement CPU reset and halting Peter Crosthwaite
2013-03-04 12:03 ` [Qemu-devel] [RFC PATCH v1 0/7] Reset and Halting modifications + Zynq SMP Andreas Färber
2013-03-04 12:57 ` Peter Crosthwaite
2013-03-29 2:49 ` Edgar E. Iglesias
2013-03-30 8:13 ` Edgar E. Iglesias [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=20130330081315.GC21321@smtp.vpn \
--to=edgar.iglesias@gmail.com \
--cc=andreas.faerber@suse.de \
--cc=dantesu@faraday-tech.com \
--cc=peter.crosthwaite@xilinx.com \
--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.