[Qemu-devel] Morph cpu_reset -> device_reset

[Qemu-devel] Morph cpu_reset -> device_reset

[Peter Crosthwaite]

Hi Andreas, Anthony,

A while ago, TYPE_CPU was refactored to by a child of TYPE_DEVICE. As
something of a hangover though, CPU has a separate reset fn to device.
This means

device_reset(DEVICE(my_cpu));

doesn't actually work as a reset. Should we fix this by getting rif of
cpu_reset and just using the device reset API for cpu reset?

Regards,
Peter

Re: [Qemu-devel] Morph cpu_reset -> device_reset

[Andreas Färber]

Hi Peter,

Am 15.07.2013 06:02, schrieb Peter Crosthwaite:
> A while ago, TYPE_CPU was refactored to by a child of TYPE_DEVICE. As
> something of a hangover though, CPU has a separate reset fn to device.
> This means
> 
> device_reset(DEVICE(my_cpu));
> 
> doesn't actually work as a reset. Should we fix this by getting rif of
> cpu_reset and just using the device reset API for cpu reset?

This question has come up a number of times, cf. the archives. For one,
CPU reset is a mess with most CPUs not registering reset handlers of
their own like devices do but having machines do that and piggy-back
some machine-specific initialization, possibly even relying on execution
order of reset handlers. For another, some forms of Soft Reset (e.g.,
kdump on s390x) will require to reset devices only but not CPUs -
currently qdev_devices_reset() calls all reset handlers, not just
devices as the name might imply.

For now you can reset a CPU via

cpu_reset(CPU(my_cpu));

and if you have a good suggestion to clean this up, that will be
appreciated. So far, a CPUClass method (1:1) and Notifiers (1:n) were
the ideas that I brought up.

Regards,
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] Morph cpu_reset -> device_reset

[Peter Crosthwaite]

Hi Andreas,

On Mon, Jul 15, 2013 at 7:55 PM, Andreas Färber <afaerber@suse.de> wrote:
> Hi Peter,
>
> Am 15.07.2013 06:02, schrieb Peter Crosthwaite:
>> A while ago, TYPE_CPU was refactored to by a child of TYPE_DEVICE. As
>> something of a hangover though, CPU has a separate reset fn to device.
>> This means
>>
>> device_reset(DEVICE(my_cpu));
>>
>> doesn't actually work as a reset. Should we fix this by getting rif of
>> cpu_reset and just using the device reset API for cpu reset?
>
> This question has come up a number of times, cf. the archives. For one,
> CPU reset is a mess with most CPUs not registering reset handlers of
> their own like devices do but having machines do that and piggy-back
> some machine-specific initialization, possibly even relying on execution
> order of reset handlers.

So some architectures are going to be a lot easier than others and if
this is considered the right thing to do, we can convert some of easy
ones and scratch our heads later re the machine quirks. I can speak
for Microblaze as being as easy one. ARM doesn't look that scary
either - and thats the one I want to convert for my application.

> For another, some forms of Soft Reset (e.g.,
> kdump on s390x) will require to reset devices only but not CPUs -
> currently qdev_devices_reset() calls all reset handlers, not just
> devices as the name might imply.
>
> For now you can reset a CPU via
>
> cpu_reset(CPU(my_cpu));
>

So my application is clock controllers, which have a uniform reset
mechanism. I want to avoid having to give my clock controller CPU
awareness for the sake of being able to do a reset. Infact, I dont
event want my controller know what its resetting, all it gets is a
link to a TYPE_DEVICE which it can then reset. Not possible with CPUs
unless you:

if (object_dynamic_cast(my_dev, TYPE_CPU))
   cpu_reset(...);
else
   device_reset(...);

Regards,
Peter

> and if you have a good suggestion to clean this up, that will be
> appreciated. So far, a CPUClass method (1:1) and Notifiers (1:n) were
> the ideas that I brought up.
>
> Regards,
> 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] Morph cpu_reset -> device_reset

[Andreas Färber]

Am 15.07.2013 12:45, schrieb Peter Crosthwaite:
> Hi Andreas,
> 
> On Mon, Jul 15, 2013 at 7:55 PM, Andreas Färber <afaerber@suse.de> wrote:
>> Hi Peter,
>>
>> Am 15.07.2013 06:02, schrieb Peter Crosthwaite:
>>> A while ago, TYPE_CPU was refactored to by a child of TYPE_DEVICE. As
>>> something of a hangover though, CPU has a separate reset fn to device.
>>> This means
>>>
>>> device_reset(DEVICE(my_cpu));
>>>
>>> doesn't actually work as a reset. Should we fix this by getting rif of
>>> cpu_reset and just using the device reset API for cpu reset?
>>
>> This question has come up a number of times, cf. the archives. For one,
>> CPU reset is a mess with most CPUs not registering reset handlers of
>> their own like devices do but having machines do that and piggy-back
>> some machine-specific initialization, possibly even relying on execution
>> order of reset handlers.
> 
> So some architectures are going to be a lot easier than others and if
> this is considered the right thing to do, we can convert some of easy
> ones and scratch our heads later re the machine quirks. I can speak
> for Microblaze as being as easy one. ARM doesn't look that scary
> either - and thats the one I want to convert for my application.

See hw/arm/boot.c for where such piggy-backing happens in ARM.

>> For another, some forms of Soft Reset (e.g.,
>> kdump on s390x) will require to reset devices only but not CPUs -
>> currently qdev_devices_reset() calls all reset handlers, not just
>> devices as the name might imply.
>>
>> For now you can reset a CPU via
>>
>> cpu_reset(CPU(my_cpu));
>>
> 
> So my application is clock controllers, which have a uniform reset
> mechanism. I want to avoid having to give my clock controller CPU
> awareness for the sake of being able to do a reset. Infact, I dont
> event want my controller know what its resetting, all it gets is a
> link to a TYPE_DEVICE which it can then reset. Not possible with CPUs
> unless you:
> 
> if (object_dynamic_cast(my_dev, TYPE_CPU))
>    cpu_reset(...);
> else
>    device_reset(...);

Sounds what you are looking for is rather a qemu_irq pin, which Anthony
has been promoting for soft resets, too.

Note that if we made device_reset() work on a CPU then we would need to
place that type check elsewhere still.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg