qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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(-)
> 
> 

      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 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).