[vbox-dev] Question regarding - tr.flags and TSS_BUSY
michal.necasek at oracle.com
Thu Mar 16 23:00:49 UTC 2017
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