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

[David Woodhouse]

On Tue, 2013-02-19 at 16:17 -0600, Anthony Liguori wrote:
> 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 :-)

Hey, don't ask me. I was just trying to do what Paolo said in response
to me first attempt — which just accessed the 'hard reset' flag in the
PIIX directly from the I440FX reset handler.

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

Yes. The Reset Control Register is in the PIIX. And the i440fx just
happens to be the only other device that *cares* if it's a hard reset or
a soft reset. For now. Thankfully they're implemented in the same C file
and even initialised together, which lets us do a special-case hack
relatively easily.

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

Sounds good to me. I'm beginning to wish I'd just ignored the fact that
we need a properly working "soft" reset to get back from 286 protected
mode to real mode, and wired up the damn PAM reset unconditionally. I'm
not convinced that the protected->real mode transition will work for
anyone anyway.

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

That was basically my first attempt, before Paulo's feedback? I had
i440fx calling into PIIX to *read* the flag, rather than PIIX calling
into i440fx to *set* it, but if you feel strongly it wouldn't be hard to
switch that round.

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature