qemu-devel
[Top][All Lists]
Advanced

[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



reply via email to

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