qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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

  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).