qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@web.de>
To: "Roedel, Joerg" <Joerg.Roedel@amd.com>
Cc: Gleb Natapov <gleb@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Erik van der Kouwe <vdkouwe@cs.vu.nl>
Subject: [Qemu-devel] Re: SVM emulation: EVENTINJ marked valid when a pagefault happens while issuing a software interrupt
Date: Fri, 28 May 2010 09:47:25 +0200	[thread overview]
Message-ID: <4BFF750D.70309@web.de> (raw)
In-Reply-To: <20100528073346.GC3266@amd.com>

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

Roedel, Joerg wrote:
> On Thu, May 27, 2010 at 06:20:00PM -0400, Jan Kiszka wrote:
>> Erik van der Kouwe wrote:
>>> Problem is: I'm compiling in Linux and testing in MINIX. Testing on the
>>> real hardware would require a reboot everytime. Moreover, it might screw
>>> up my system if I make bad mistakes (the MINIX filesystem is easily
>>> corrupted).
>> Use Linux+KVM as host OS, it can also run VMMs as guests (aka nested
>> SVM). And you could even debug those guests just like when you would run
>> QEMU in emulation mode. In contrast to SVM emulation, nesting is fairly
>> stable AFAIK. And it is faster.
> 
> At least it is more stable than any other nested-svm implementation I
> know of ;-)
> There are issues with kvmclock when you run kvm-on-kvm and you should
> not expect windows-based hypervisors to run without problems. Beside
> that, for running kvm-on-kvm and xen-on-kvm it is indeed fairly
> stable :-)
> 
>>> Linux source tree (2.6.31-ubuntu), arch/x86/kvm/svm.c, end of function
>>> nested_svm_vmrun. Here event_inj and event_inj_err are copied from a
>>> different VMCB, effectively clearing the value set by the CPU. Maybe
>>> this isn't were I should have been looking though?
> 
> The interesting part is in nested_svm_vmexit. There you have this piece
> of code:
> 
>         /*
>          * If we emulate a VMRUN/#VMEXIT in the same host #vmexit cycle we have
>          * to make sure that we do not lose injected events. So check event_inj
>          * here and copy it to exit_int_info if it is valid.
>          * Exit_int_info and event_inj can't be both valid because the case
>          * below only happens on a VMRUN instruction intercept which has
>          * no valid exit_int_info set.
>          */
>         if (vmcb->control.event_inj & SVM_EVTINJ_VALID) {
>                 struct vmcb_control_area *nc = &nested_vmcb->control;
> 
>                 nc->exit_int_info     = vmcb->control.event_inj;
>                 nc->exit_int_info_err = vmcb->control.event_inj_err;
>         }
> 
> and a few lines later:
> 
>         nested_vmcb->control.event_inj         = 0;
>         nested_vmcb->control.event_inj_err     = 0;
> 
> ... which takes care of this situation. The vmcb.eventinf field is _defined_ to
> be zero on a #vmexit.

(Hmm, must have missed that line in the spec.)

In that case something like

diff --git a/target-i386/op_helper.c b/target-i386/op_helper.c
index dcbdfe7..caabdb4 100644
--- a/target-i386/op_helper.c
+++ b/target-i386/op_helper.c
@@ -1263,13 +1263,6 @@ void do_interrupt(int intno, int is_int, int error_code,
 #endif
         do_interrupt_real(intno, is_int, error_code, next_eip);
     }
-
-#if !defined(CONFIG_USER_ONLY)
-    if (env->hflags & HF_SVMI_MASK) {
-	    uint32_t event_inj = ldl_phys(env->vm_vmcb + offsetof(struct vmcb, control.event_inj));
-	    stl_phys(env->vm_vmcb + offsetof(struct vmcb, control.event_inj), event_inj & ~SVM_EVTINJ_VALID);
-    }
-#endif
 }
 
 /* This should come from sysemu.h - if we could include it here... */
@@ -5388,6 +5381,7 @@ void helper_vmexit(uint32_t exit_code, uint64_t exit_info_1)
              ldl_phys(env->vm_vmcb + offsetof(struct vmcb, control.event_inj)));
     stl_phys(env->vm_vmcb + offsetof(struct vmcb, control.exit_int_info_err),
              ldl_phys(env->vm_vmcb + offsetof(struct vmcb, control.event_inj_err)));
+    stl_phys(env->vm_vmcb + offsetof(struct vmcb, control.event_inj), 0);
 
     env->hflags2 &= ~HF2_GIF_MASK;
     /* FIXME: Resets the current ASID register to zero (host ASID). */

should resolve the QEMU issue, right?

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

  reply	other threads:[~2010-05-28  7:47 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 [this message]
2010-05-28  7:24   ` Roedel, Joerg
2010-05-28  7:45     ` Erik van der Kouwe
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=4BFF750D.70309@web.de \
    --to=jan.kiszka@web.de \
    --cc=Joerg.Roedel@amd.com \
    --cc=gleb@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=vdkouwe@cs.vu.nl \
    /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).