Re: [Qemu-devel] [RFC PATCH] Distinguish between reset types

[Anthony Liguori]

David Woodhouse <address@hidden> writes:

> On Tue, 2013-02-19 at 14:29 -0600, Anthony Liguori wrote:
>> David Woodhouse <address@hidden> writes:
>> >      if (val & 4) {
>> > +        if (val & 2)
>> > +            qemu_irq_pulse(d->reset_out);
>> >          qemu_system_reset_request();
>> 
>> 
>> This is a bit strange to me. 
>
> The reset_out "IRQ" isn't actually what triggers the I440FX/PAM reset.

Right, this is what's strange to me.  There's no hardware analog AFAICT
so I'm not sure why we're exposing it as a qemu_irq other than we want
to jump through a function pointer invocation instead of making a
straight funciton call :-)

> That just sets a flag to say that the coming *system* reset is a hard
> reset and not a soft reset.

Yes, but this flag is in PIIX, not the i440fx.

> I did comment about the possibility of doing
> the reset directly from the qemu_irq handler, and why I hadn't done it
> that way...
>
>> So should we even be resetting anything other than the CPU during soft
>> reset?
>
> I suspect not. A soft reset triggered by the RCR, keyboard controller,
> port 92 etc. should all just reset the CPU and nothing else.

I suspect what we need to do is convert qemu_system_reset_request() into
a qemu_system_cpu_reset() that takes a callback.  Once the VCPUs have
been reset, the callback can then be used to reset all or some of the
device model.  This of course means removing the reset handlers in the
CPUs as they exist today.

Cc'ing Andreas to get his thoughts.

FWIW, I'm not expecting you to do this to fix this issue.  Just thinking
out loud here really.

>> In the very least, shouldn't we expose qemu_irqs from the PIIX and let
>> the i440fx decide what to do with them?  In this case, it would be an
>> INIT# and CPURST# qemu_irq corresponding to soft and hard reset
>> respectively.
>
> How far down this road do we go? Do we end up wiring up the full reset
> topology and abandoning the special-case qemu_system_reset()
> altogether?

Long term, yes.  Short term, whatever we need that's reasonable to get
the CSM happy without making things worse.

I'm not terribly happy exposing an IRQ that doesn't exist in real life
to "model hardware".  We could just as easily call into i440fx to set
the hard_reset flag without jumping through qemu_irq hoops if we're just
looking to make it work.  I think that's clearer if what we're doing is
essentially a short term hack.

If we were going to model an INIT# and CPURST# qemu_irq and raise them
based on what the hardware does, I'm happy with that.  But AFAICT
'reset_out' has no hardware analogy.

Regards,

Anthony Liguori

>
> -- 
> dwmw2