From: Avi Kivity <avi@qumranet.com>
To: Hollis Blanchard <hollisb@us.ibm.com>
Cc: Jan Kiszka <jan.kiszka@web.de>, kvm-devel <kvm@vger.kernel.org>
Subject: Re: [kvm-devel] [RFC][PATCH 3/4] kvm-vmx: KVM_EXIT_DEBUG on #BP exceptions
Date: Sun, 25 May 2008 13:24:27 +0300 [thread overview]
Message-ID: <48393E5B.2040904@qumranet.com> (raw)
In-Reply-To: <200805221327.43434.hollisb@us.ibm.com>
Hollis Blanchard wrote:
>
>> We mostly try to keep cpu emulation outside userspace.
>>
>
> Except for this debug stuff? :)
>
>
Except when it's on the wrong side of the complexity/benefit or
performance/cleanliness tradeoffs.
>> (of course, that depends on what happens on real hardware. Is there a
>> machine check pin? or does the cpu generate the exception internally?)
>>
>
> There is a machine check pin, FWIW. It's the chipset (potentially several IO
> bridges away) that discovers no device decoded the MMIO address, and
> asynchronously notifies the core.
>
> I'm happy with machine check as an "MMIO failed" flag, so I guess that leaves
> us with a separate "inject debug event" ioctl.
>
In that case it's more reasonable to have a machine check ioctl. Are
the other chipset-discovered causes of this? Perhaps on other ppc boards?
The x86 analog is triple faults. On real hardware, a triple fault
asserts a processor pin and shuts down the processor. The motherboard
detects this and causes a system reset. So we have a triple fault exit
reason, and reset generation happens in userspace.
--
error compiling committee.c: too many arguments to function
next prev parent reply other threads:[~2008-05-25 10:24 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <482D9198.7040801@web.de>
2008-05-16 16:01 ` [RFC][PATCH 1/4] qemu: refactor cpu_watch/breakpoint API Jan Kiszka
2008-05-16 16:01 ` [RFC][PATCH 2/4] kvm: Arch-specifc KVM_EXIT_DEBUG payload Jan Kiszka
2008-05-21 15:59 ` [kvm-devel] " Avi Kivity
2008-05-22 13:27 ` Jan Kiszka
2008-05-21 16:04 ` Avi Kivity
2008-05-22 13:42 ` Jan Kiszka
2008-05-22 13:59 ` Avi Kivity
2008-05-22 14:32 ` Jan Kiszka
2008-05-22 14:35 ` Avi Kivity
2008-05-16 16:02 ` [RFC][PATCH 3/4] kvm-vmx: KVM_EXIT_DEBUG on #BP exceptions Jan Kiszka
2008-05-21 16:01 ` [kvm-devel] " Avi Kivity
2008-05-22 13:31 ` Jan Kiszka
2008-05-22 13:58 ` Avi Kivity
2008-05-22 14:24 ` Jan Kiszka
2008-05-22 14:31 ` Avi Kivity
2008-05-22 14:26 ` Hollis Blanchard
2008-05-22 14:34 ` Avi Kivity
2008-05-22 18:27 ` Hollis Blanchard
2008-05-25 10:24 ` Avi Kivity [this message]
2008-05-16 16:02 ` [RFC][PATCH 4/4] kvm-userspace: use soft-BPs for guest debugging Jan Kiszka
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=48393E5B.2040904@qumranet.com \
--to=avi@qumranet.com \
--cc=hollisb@us.ibm.com \
--cc=jan.kiszka@web.de \
--cc=kvm@vger.kernel.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.