From: Erik van der Kouwe <vdkouwe@cs.vu.nl>
To: "Roedel, Joerg" <Joerg.Roedel@amd.com>
Cc: Jan Kiszka <jan.kiszka@web.de>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
Gleb Natapov <gleb@redhat.com>
Subject: [Qemu-devel] Re: SVM emulation: EVENTINJ marked valid when a pagefault happens while issuing a software interrupt
Date: Fri, 28 May 2010 09:45:09 +0200 [thread overview]
Message-ID: <4BFF7485.3000606@cs.vu.nl> (raw)
In-Reply-To: <20100528072405.GB3266@amd.com>
Hi,
Thankss for your answer.
> SVM always clears the vmcb.eventinj on vmrun because every exception is
> injected right after vmrun finished and cpu is in guest mode. It can
> happen (for example if taking the exception causes a page fault) that
> the vmcb.eventinj field is copied to vmcb.exit_int_info.
Yes, this s what I have been experiencing.
> In nested-svm you can get a valid exit_int_info when an interrupt or nmi
> is pending too. In the software implementation these intercepts are
> taken before the event is delivered and you find the event in
> vmcb.exit_int_info.
> This is not forbidden in the svm architecture and I have not found a
> hypervisor that has a problem with this different behavior. I have a
> patch here which changes this in nested-svm, but it introduces more
> problems than it fixes.
This is a ok, the problem is the event_inj field rather than the
exit_int_info field. From what I've seen the SVM specification neither
specifies that the CPU writes to this field nor does it explicitly
forbid it. Given the unclarity of the specification it may safest to
deal with this in the same way as the hardware does (although I don't
know which way this is, it seems inuitively unlikely that the hardware
would set event_inj to valid).
With kind regards,
Erik
next prev parent reply other threads:[~2010-05-28 7:45 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-27 15:26 [Qemu-devel] SVM emulation: EVENTINJ marked valid when a pagefault happens while issuing a software interrupt Erik van der Kouwe
2010-05-27 18:53 ` [Qemu-devel] " Jan Kiszka
2010-05-27 19:49 ` Erik van der Kouwe
2010-05-27 22:20 ` Jan Kiszka
2010-05-28 5:13 ` Erik van der Kouwe
2010-05-28 6:10 ` Jan Kiszka
2010-05-28 7:35 ` Roedel, Joerg
2010-05-28 13:20 ` Jamie Lokier
2010-05-28 13:30 ` Erik van der Kouwe
2010-05-28 13:44 ` Roedel, Joerg
2010-05-28 13:52 ` Erik van der Kouwe
2010-05-28 13:32 ` Roedel, Joerg
2010-05-28 7:33 ` Roedel, Joerg
2010-05-28 7:47 ` Jan Kiszka
2010-05-28 7:24 ` Roedel, Joerg
2010-05-28 7:45 ` Erik van der Kouwe [this message]
2010-05-28 9:12 ` Roedel, Joerg
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=4BFF7485.3000606@cs.vu.nl \
--to=vdkouwe@cs.vu.nl \
--cc=Joerg.Roedel@amd.com \
--cc=gleb@redhat.com \
--cc=jan.kiszka@web.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).