All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@web.de>
To: qemu-devel@nongnu.org
Cc: kwolf@suse.de
Subject: [Qemu-devel] Re: [RESENT][PATCH 2/2] x86: Issue reset on triple faults
Date: Tue, 24 Jun 2008 08:39:46 +0200	[thread overview]
Message-ID: <486096B2.1000407@web.de> (raw)
In-Reply-To: <20080623160047.GB16803@shareable.org>

[-- Attachment #1: Type: text/plain, Size: 2040 bytes --]

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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 258 bytes --]

  parent reply	other threads:[~2008-06-24  6:39 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-23 15:15 [Qemu-devel] [RESENT][PATCH 2/2] x86: Issue reset on triple faults Jan Kiszka
2008-06-23 15:23 ` Jamie Lokier
2008-06-23 15:35   ` [Qemu-devel] " Jan Kiszka
2008-06-23 16:00     ` Jamie Lokier
2008-06-23 20:01       ` Natalia Portillo
2008-06-24  6:39       ` Jan Kiszka [this message]
2008-06-24  8:18     ` Kevin Wolf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=486096B2.1000407@web.de \
    --to=jan.kiszka@web.de \
    --cc=kwolf@suse.de \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.