Re: CPU reset vs DeviceState reset

[Eduardo Habkost]

On Mon, Mar 02, 2020 at 06:41:31PM +0000, Peter Maydell wrote:
> On Mon, 2 Mar 2020 at 17:45, Eduardo Habkost <address@hidden> 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.
> 
> I think we can just make the cpu_reset() function be a
> wrapper that calls device_cold_reset(DEVICE(cpu)).
> We would need to update the prototypes for

[1] This might have unintended side effects, as it will also call
    cpu_common_reset().  I still think we should try it.

> 
> > 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.
> 
> At least for Arm CPUs, I don't think it does (well, it
> has the default DeviceState base class reset method
> which does nothing). Is there somewhere I missed?

TYPE_CPU points DeviceClass::reset to cpu_common_reset(),
so I believe this affects all TYPE_CPU descendants.

> 
> (I'm currently attempting to wrestle Coccinelle into
> doing the conversion of the target/ code automatically.)

I see 3 separate problems we might want to address:

1) Making device_cold_reset() end up calling CPUClass::reset
   in addition to existing cpu_common_reset()
   (easier to do without side effects).  This would get rid of
   the custom reset callbacks on machine code.

2) Making cpu_reset() call device_cold_reset()
   (will have side effects, needs additional care[1]).
   This would make us have only one method of resetting CPUs.

3) Replacing CPUClass::reset with the new reset mechanisms..
   This would let us get rid of legacy CPU reset code.

-- 
Eduardo