On Tue, 2013-02-19 at 14:29 -0600, Anthony Liguori wrote: > David Woodhouse <dw...@infradead.org> 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
smime.p7s
Description: S/MIME cryptographic signature