[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
smime.p7s
Description: S/MIME cryptographic signature
- Re: [Qemu-devel] [RFC PATCH] Distinguish between reset types, (continued)
- Re: [Qemu-devel] [RFC PATCH] Distinguish between reset types, Paolo Bonzini, 2013/02/19
- Re: [Qemu-devel] [RFC PATCH] Distinguish between reset types, David Woodhouse, 2013/02/19
- Re: [Qemu-devel] [RFC PATCH] Distinguish between reset types, Anthony Liguori, 2013/02/19
- Re: [Qemu-devel] [RFC PATCH] Distinguish between reset types, David Woodhouse, 2013/02/19
- Re: [Qemu-devel] [RFC PATCH] Distinguish between reset types, Paolo Bonzini, 2013/02/19
- Re: [Qemu-devel] [RFC PATCH] Distinguish between reset types, Peter Maydell, 2013/02/19
Re: [Qemu-devel] [RFC PATCH] Distinguish between reset types, Andreas Färber, 2013/02/19
Re: [Qemu-devel] [RFC PATCH] Distinguish between reset types, Anthony Liguori, 2013/02/19
Re: [Qemu-devel] [RFC PATCH] Distinguish between reset types, Peter Maydell, 2013/02/19
- Re: [Qemu-devel] [RFC PATCH] Distinguish between reset types,
David Woodhouse <=