qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Roedel, Joerg" <Joerg.Roedel@amd.com>
To: Jan Kiszka <jan.kiszka@web.de>
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:33:46 +0200	[thread overview]
Message-ID: <20100528073346.GC3266@amd.com> (raw)
In-Reply-To: <4BFEF010.50300@web.de>

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.

	Joerg

  parent reply	other threads:[~2010-05-28  8:04 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 [this message]
2010-05-28  7:47         ` Jan Kiszka
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=20100528073346.GC3266@amd.com \
    --to=joerg.roedel@amd.com \
    --cc=gleb@redhat.com \
    --cc=jan.kiszka@web.de \
    --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).