Re: CPU reset vs DeviceState reset

[Philippe Mathieu-Daudé]

On 3/2/20 6:45 PM, Eduardo Habkost wrote:
> My impression is that this is just historical legacy, but I'm not
> sure how much work a conversion to the new system would require.
> I see lots of cpu_reset() calls scattered around the code.
>
> To make it worse, TYPE_CPU do have a DeviceClass::reset method
> implemented, but cpu_reset() won't call it because it bypasses
> the Device reset system completely.  I will do some git
> archaeology work to try to find out why the code is this way.

Without verifying the code base/commits, my understanding is that was 
required to use cpu object with linux-user before Markus added support 
for anonymous object container for QOM objects on linux-user. So now we 
could make CPUClass inherits of DeviceClass.

> On Mon, Mar 02, 2020 at 05:20:33PM +0000, Peter Maydell wrote:
> > Hi; I've just noticed that although TYPE_CPU is a subclass of
> > TYPE_DEVICE, it seems to implement its own reset method
> > ('reset' field in CPUClass struct) rather than just using the
> > DeviceClass's 'reset'.
> >
> > Is there a reason for doing this, or is it just historical legacy
> > from TYPE_CPU originally not being a subclass of TYPE_DEVICE?
> >
> > I ask because I'd like to be able to use 3-phase reset in the Arm
> > CPU, and I'm wondering whether it would be better to make TYPE_CPU
> > just use Device's reset system, or to treat TYPE_CPU as its own
> > base class and implement Resettable there. The former seems more
> > straightforward, unless I'm missing something that means we
> > really do need to have the reset method be different.
> >
> > thanks
> > -- PMM