qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: [RESENT][PATCH 2/2] x86: Issue reset on triple faults


From: Jan Kiszka
Subject: [Qemu-devel] Re: [RESENT][PATCH 2/2] x86: Issue reset on triple faults
Date: Tue, 24 Jun 2008 08:39:46 +0200
User-agent: Thunderbird 2.0.0.14 (Windows/20080421)

Jamie Lokier wrote:
Jan Kiszka wrote:
It might be worth distinguishing between
triple-fault-used-by-guest-for-context-switch and triple faults which
trigger a normal reset, and log only the latter.  There's a
standardish way of distinguishing them, which the BIOS should check.
You refer to setting some return address at some magic BIOS location?

Probably; I forget the details.  There might be a CMOS byte, too.

I checked some old documents: It's a combination of both. Some CMOS byte (0x0f) signals the special reset, and a pointer in the BIOS memory (0x40:0x67) describes the desired jump target.


Isn't this something the BIOS should handle, not QEMU?

The BIOS should handle it, yes.  But since it is standard behaviour,
it might be useful for QEMU to decide whether to _log_ the event as a
system reset based on that state.

Yeah, meanwhile my brain seems to work again and actually read what you mean.

But I'm still not convinced that we should make a special case about this in the QEMU core. The user is not forced to enable reset logging, and maybe (s)he _does_ want to log also resets due to protected mode exits - what then? Keep it simple, just log what actually happens if logging is enabled.


Same for keyboard controller induced reset - that's also used for
context switching, in the same way.  (Triple fault is only used
because it's faster.)

Same also for deciding whether -no-reboot should close down the QEMU
process.  Now I think about it, that is the best reason to distinguish
them!

When helper(SVM_EXIT_SHUTDOWN, 0) is called, should it still also call
qemu_system_reset_request()?
helper_vmexit() is not expected to return (cpu_loop_exit).

Ok.  It's not clear unless you know the code, which I don't.  Just
wanted to check :-)

Understanding the usage of setjmp/longjmp in QEMU is a key to grasp the control flow - but it took me some time as well to realize this. :)

Jan

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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