From: Jan Kiszka <jan.kiszka@web.de>
To: Erik van der Kouwe <vdkouwe@cs.vu.nl>
Cc: Joerg Roedel <joerg.roedel@amd.com>,
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 00:20:00 +0200 [thread overview]
Message-ID: <4BFEF010.50300@web.de> (raw)
In-Reply-To: <4BFECCC3.2000806@cs.vu.nl>
[-- Attachment #1: Type: text/plain, Size: 2576 bytes --]
Erik van der Kouwe wrote:
> Hi,
>
>> Be warned: Though my experience is already more than a year old, the SVM
>> emulation in QEMU is most probably not yet rock-stable. Always check
>> suspicious behavior against real hardware and/or the spec. [ As real
>> hardware is everywhere, nesting works with KVM+SVM and is much faster,
>> motivation to improve QEMU in this area is unfortunately limited. ]
>
> 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.
>
> That said, I do aim to eventually test the real hardware. Plenty of
> virtualization capable hardware where I work, although unfortunately all
> Intel.
>
>>> This issue is easy to work around by clearing the EVENTINJ field on each
>>> #VMEXIT (and I have submitted a patch to that effect to the Palacios
>>> people) and this approach is also found in KVM.
>>
>> /me does not find such clearing in KVM - what line(s) are you looking at?
>
> 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?
Yep. This is the path taken for injecting events when switching from
level-1 to level-2 guests, i.e. you are running some VMM inside KVM.
>
>>> The relevant code is in target-i386/op_helper.c. The "handle_even_inj"
>>> function sets the EVENTINJ field (called event_inf in the QEMU code) and
>>> the helper_vmexit function copies that field into EXITINTINFO
>>> (exit_int_info in the QEMU code). I believe (but once again, am not
>>> certain) that the SVM documentation only says that this information
>>> should be stored in EXITINTINFO.
>>
>> Yes, this also looks suspicious. handle_even_inj should not push the
>> real (level 1) event to be injected into event_inj[_err] but into
>> exit_int_info[_err] or some temporary fields from which the exit info is
>> then loaded later on.
>
> Yes, if this is indeed incorrect behaviour then this is what I would
> expect a fix to be like.
>
> Thanks again,
> Erik
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]
next prev parent reply other threads:[~2010-05-27 22:41 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 [this message]
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
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=4BFEF010.50300@web.de \
--to=jan.kiszka@web.de \
--cc=gleb@redhat.com \
--cc=joerg.roedel@amd.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).