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 13:58:10 +0000

On Tue, 2013-02-19 at 12:04 +0000, Peter Maydell wrote:
> I'm dubious about this. At the moment we have one set of reset
> semantics, which is "this works as if you yanked the power to
> the machine and plugged it back in again".

Except when it doesn't. Such as the PAM registers on the i440FX, which
*don't* reset themselves to the poweron state during a reset. And when I
posted the naïve patch to 'fix' that, it was pointed out to me that some
resets *shouldn't* do that.

>  We also have a number of cases of device-local "software reset" where
> the device internally resets just some of its state when the guest
> prods an appropriate register.

Yeah, when it's truly device-local that's different and fairly trivial
to handle.

> If you want any other kind of reset, we have to start actually
> really modelling the hardware with all the various reset lines
> and so on. So a keyboard controller triggered reset should work
> by asserting a gpio line which probably goes to some kind of power
> controller which in turn causes various other devices to act in
> whatever way the hardware acts for soft reset.

Maybe, although often these reset lines *are* system-wide. The 'soft'
vs. 'hard' distinction isn't something that the core code actually cares
about; its precise definition is a matter to be agreed between the
platform and the device drivers which run on that platform. It would be
trivial to extend the enum to handle additional values if a given
platform actually needed to.

> Basically, I don't think you can come up with a definition of
> "soft reset" that makes sense across the range of architectures
> and boards that we model in QEMU.

No, but (as discussed above) I don't think we *need* to have such a
universal definition, either.

But I'm not particularly wedded to this approach; we can do it with a
hack directly in piix_pci.c too. To a certain extent, this is just a
straw man, to show that the local hack isn't such a bad thing after
all :)

-- 
dwmw2

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


reply via email to

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