On 02/19/13 23:45, David Woodhouse wrote:
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 believe currently we must be somewhere "between" soft reset & hard reset. I estimate getting closer to a well-emulated hard reset is more important than getting closer to a soft one. If you were to extend the i440FX reset handler so that it unconditionally resets the PAMs, I'd give my Rb. (Take it for what it's worth :))
The long-term solution covering all targets is being designed, but a quick shortcut would be nice, and not only for CSM development / testing. (I gather qemu_prep_reset() in SeaBIOS would not have had to be written that way, for example.) For CSM stuff we can still carry private qemu patches of course...
Thanks Laszlo
Il 20/02/2013 16:18, Laszlo Ersek ha scritto:
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 believe currently we must be somewhere "between" soft reset & hard reset. I estimate getting closer to a well-emulated hard reset is more important than getting closer to a soft one. If you were to extend the i440FX reset handler so that it unconditionally resets the PAMs, I'd give my Rb. (Take it for what it's worth :))
It would actually make sense. The right way to do soft reset has nothing to do with qemu_system_reset_request().
Paolo
On Wed, 2013-02-20 at 16:34 +0100, Paolo Bonzini wrote:
Il 20/02/2013 16:18, Laszlo Ersek ha scritto:
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 believe currently we must be somewhere "between" soft reset & hard reset. I estimate getting closer to a well-emulated hard reset is more important than getting closer to a soft one. If you were to extend the i440FX reset handler so that it unconditionally resets the PAMs, I'd give my Rb. (Take it for what it's worth :))
It would actually make sense. The right way to do soft reset has nothing to do with qemu_system_reset_request().
I've posted that version of the patch, with a suitable comment.
Thanks.
On 02/20/2013 07:37 AM, David Woodhouse wrote:
On Wed, 2013-02-20 at 16:34 +0100, Paolo Bonzini wrote:
Il 20/02/2013 16:18, Laszlo Ersek ha scritto:
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 believe currently we must be somewhere "between" soft reset & hard reset. I estimate getting closer to a well-emulated hard reset is more important than getting closer to a soft one. If you were to extend the i440FX reset handler so that it unconditionally resets the PAMs, I'd give my Rb. (Take it for what it's worth :))
It would actually make sense. The right way to do soft reset has nothing to do with qemu_system_reset_request().
I've posted that version of the patch, with a suitable comment.
Right... the "soft reset" described above is really INIT, which isn't even a reset in modern CPUs (it couldn't be, it has to preserve caches) but more of a special interrupt. It is also used during multiprocessor init.
-hpa
-
David Woodhouse -
H. Peter Anvin -
Laszlo Ersek -
Paolo Bonzini