[vbox-dev] Question regarding - tr.flags and TSS_BUSY
alexander.boettcher at genode-labs.com
Mon Mar 20 21:19:54 UTC 2017
ok, here are the information I have and some points if you want try to
reproduce it. (You will need 2.4.1 or the upcoming 2.9 Qemu release to
reproduce it) :
The guest is a a trivial 32bit Genode/NOVA setup (the iso and the output
of a run in Qemu 2.4.1 see [0,1]). It uses sysenter/sysexit, I/O APIC is
required and the output is available via the serial device.
qemu-system-x86_64 -no-kvm -cpu core2duo -nographic -m 64 -cdrom log.iso
This log.iso is then added as VM to a 64bit Genode/NOVA + VBox (4.3.40)
port to run it as VM.
This setup is executed on a emulated 64 bit host (Qemu + AMD-V SVM
extension enabled [2,3] by using:
qemu-system-x86_64 -nographic -no-kvm -m 512 -cpu phenom -serial
mon:stdio -cdrom vbox4_tss_bad.iso
With the proposed tss fix the issue is gone [4,5].
According to Qemu, a interrupt  happens in ring-3 (cpl==3), where the
tr/tss is used to look up the ss & esp register to switch to ring-0
(dpl==0) . Then the assertion triggers as shown in  by the line of
 in Qemu.
I hope this helps. At the moment I am not able to trigger the issue in
the Vbox5 port reliable, thats-why I solely added the vbox4 version.
On 17.03.2017 00:00, Michal Necasek wrote:
> Hi Alexander,
> Thanks for the information. I believe you that there is a problem, and the comments in the code indicate as much, but I still don't understand the failure scenario on the virtual CPU level.
> Can you confirm that there is task switching involved in a 32-bit guest? Can you please explain exactly at what point the incorrect TSS busy bit value triggers problems? Is it during a task switch (I think it has to be)? What kind of a task switch is it, i.e. what triggered it? JMP, CALL, interrupt...?
> The busy flag management in the recompiler task switch (switch_tss()) looks fishy and is almost certainly wrong, but I need to understand more. And I think you're right that the VirtualBox<->recompiler transitions should leave the busy flag alone. But I still don't understand exactly how it's causing problems.
> Incidentally, what is 'Qemu+SVM'? That is not SVM as in Secure Virtual Machine aka AMD-V, is it?
> ----- Original Message -----
> From: alexander.boettcher at genode-labs.com
> To: michal.necasek at oracle.com, vbox-dev at virtualbox.org
> Sent: Monday, March 13, 2017 1:45:19 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna
> Subject: Re: [vbox-dev] Question regarding - tr.flags and TSS_BUSY
> On 10.03.2017 17:05, Michal Necasek wrote:
>> Could you please describe your use case, or rather how we can reproduce
>> the problem?
> I feared you ask - but nevertheless - when running VirtualBox inside
> Qemu+SVM (and no kvm enabled) with our ported Version of VBox to
>> This is not code we want to change without precisely
>> understanding why it needs to change and testing the behavior.
> I can imagine.
>> Also, why are you using the recompiler at all? On a typical system with
>> hardware virtualization, it should be used very little or not at all.
> Probably this is right for the vanilla Virtualbox as you provide. In our
> Vbox 4 (4.3.40) ported version we mainly use REM + hw accelerated
> (interface provided by the Microkernel NOVA), there it triggers reliable
> if running in Qemu.
> For the VBox 5 (5.1.14) port to Genode we enabled also the IEM, but here
> it also trigger in Qemu+SVM (no-kvm).
> You may have luck, Qemu just succeeds running Vbox and the VM - iif the
> preemption (due to interrupts to be injected by the VBox VMM) of the
> Guest VM (Microkernel+Genode setup) is that, that you ever get a tr
> register with set busy bit.
> I understand that our use-case is maybe of no interest to the majority
> (even we mainly use it for early debugging in Qemu) - nevertheless we
> wanted you just let know that there is a issue.
http://www.genode-labs.com - http://www.genode.org
Genode Labs GmbH - Amtsgericht Dresden - HRB 28424 - Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
More information about the vbox-dev