From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:38344) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ULqyA-0001nc-G0 for qemu-devel@nongnu.org; Sat, 30 Mar 2013 04:17:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ULqy8-0002I5-HB for qemu-devel@nongnu.org; Sat, 30 Mar 2013 04:16:58 -0400 Received: from mail-ea0-x22a.google.com ([2a00:1450:4013:c01::22a]:53303) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ULqy8-0002Hx-AK for qemu-devel@nongnu.org; Sat, 30 Mar 2013 04:16:56 -0400 Received: by mail-ea0-f170.google.com with SMTP id a15so449119eae.15 for ; Sat, 30 Mar 2013 01:16:55 -0700 (PDT) Date: Sat, 30 Mar 2013 09:13:15 +0100 From: "Edgar E. Iglesias" Message-ID: <20130330081315.GC21321@smtp.vpn> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [RFC PATCH v1 0/7] Reset and Halting modifications + Zynq SMP List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Crosthwaite Cc: andreas.faerber@suse.de, qemu-devel@nongnu.org, dantesu@faraday-tech.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(-) > >