qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: David Woodhouse
Subject: Re: [Qemu-devel] [RFC PATCH] Distinguish between reset types
Date: Tue, 19 Feb 2013 21:58:50 +0000

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.
That just sets a flag to say that the coming *system* reset is a hard
reset and not a soft reset. 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.

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

-- 
dwmw2

Attachment: smime.p7s
Description: S/MIME cryptographic signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]