[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC] ARMCPU: Halting a CPU from Device Land
From: |
Andreas Färber |
Subject: |
Re: [Qemu-devel] [RFC] ARMCPU: Halting a CPU from Device Land |
Date: |
Mon, 18 Jun 2012 12:07:17 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120421 Thunderbird/12.0 |
Hi Peter,
Am 18.06.2012 09:22, schrieb Peter Crosthwaite:
> Hi Andreas,
>
> For the Xilinx Zynq platform, we need to be able to halt a CPU from a
> device (the zynq_slcr). E.G, if I write a 1 to a register bit in my
> device, then that device effects a halt of a CPU. Looking at the QOM
> stuff the API for a CPU is (include/qemu/cpu.h):
>
> typedef struct CPUClass {
> /*< private >*/
> ObjectClass parent_class;
> /*< public >*/
>
> void (*reset)(CPUState *cpu);
> } CPUClass;
>
> The only API function is to reset a CPU. Thats means that if I link up
> my CPU to my device the only thing it can do is reset the CPU? Are
> there plans to extend this API to include some common functions such
> as halting and resuming etc? How hard is this to do in a generic (non
> ARM) way?
>
> Peter,
>
> Can it be done is an ARM specific way? Is there a one line killer to
> halt an ARM cpu that we could add the to ARMCPU API?
I'll answer both:
There's the QOM CPUState part 4 series on the list that sequentially
moves more and more fields into CPUState. So far the good news. The bad
news is that merging the halted field movement - despite on the list -
depends on refactorings of the TLB that I haven't gotten around to yet.
(Still caught up in packaging v1.1.)
The ARM-specific way is to cast your CPUState with ARM_CPU(), assuming
your Zynq device is compiled per target like most ARM devices currently
are, then you can access ->env (CPUARMState), which still has the halted
field.
Cheers,
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg