[Qemu-devel] Re: SVM emulation: EVENTINJ marked valid when a pagefault happens while issuing a software interrupt

[Jan Kiszka <jan.kiszka@web.de>]

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

Erik van der Kouwe wrote:
> Dear all,
> 
> I have been experiencing problems with duplicate delivery of software
> interrupts when running a VMM inside QEMU with SVM emulation. I believe

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

> QEMU's behaviour deviates from the SVM specification in "AMD64
> Architecture Programmer’s Manual Volume 2 System Programming" but I am
> not entirely certain because this specification isn't very clear. I
> would like to hear your views on this.
> 
> My set-up is as follows:
> Host: Linux 2.6.31-21-generic-pae (Ubuntu 9.10)
> VMM running on host: QEMU 0.12.3 (compiled from source)
> Outer guest: MINIX 3.1.7 (from SVN, see http://www.minix3.org/)
> VMM running on outer guest: Palacios 1.2.0 32-bit (from git, see
> http://www.v3vee.org/palacios/)
> Inner guest: MINIX 3.1.7 (from SVN, see http://www.minix3.org/)
> 
> The issue is the following: whenever an software interrupt instruction
> (INT n, used in this case to perform a system call) in the inner guest
> triggers a page fault (used for shadow paging by Palacios, not a real
> guest page fault), QEMU sets the EVENTINV field of the guest VMCB to the
> exit information that the software interrupt would produce and marks it
> as valid. Palacios does not overwrite the EVENTINJ field, so after the
> page fault is handled a software interrupt event is injected. After the
> IRET of the interrupt handler, control returns to the original INT n
> instruction which once again triggers the interrupt.
> 
> 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?

> 
> However, I haven't been able to find information in the AMD
> documentation that mentions that the CPU sets the valid bit in the
> EVENTINJ field so, unless I am mistaken here, I believe this behaviour
> is incorrect. QEMU stores interrupt information in both EVENTINJ and
> EXITINTINFO while I believe it should be only in the latter.
> Unfortunately I don't have a physical AMD available to verify its
> behaviour.

Based on the KVM code (which is known to work perfectly :) ), I think
you are right: SVM apparently clears the valid bit in EVENTINJ during
VMRUN once it starts processing the injection, not after it as it's the
case in current QEMU. But better ask the experts: Jörg, Gleb?

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

Jan


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