[Qemu-devel] [RFC] ARMCPU: Halting a CPU from Device Land

[Qemu-devel] [RFC] ARMCPU: Halting a CPU from Device Land

[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?

Regards,
Peter

Re: [Qemu-devel] [RFC] ARMCPU: Halting a CPU from Device Land

[Andreas Färber]

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

Re: [Qemu-devel] [RFC] ARMCPU: Halting a CPU from Device Land

[Peter Crosthwaite]

On Mon, Jun 18, 2012 at 8:07 PM, Andreas Färber <afaerber@suse.de> wrote:
> 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.

Hi Andreas,

So whats the sensible course of action implementation wise? #include
cpu.h in my device, cast to ARM_CPU(), ->env->halted = 1, with a /*
FIXME */ ?? Cos this approach seems hacky so is it really acceptable
if I were to create a series that does this today?

Regards,
Peter

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