qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC PATCH v1 0/7] Reset and Halting modifications + Zy


From: Edgar E. Iglesias
Subject: Re: [Qemu-devel] [RFC PATCH v1 0/7] Reset and Halting modifications + Zynq SMP
Date: Sat, 30 Mar 2013 09:13:15 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]