Hi,

On 23.03.2017 00:23, Michal Necasek wrote:
>  Your setup is certainly... exotic.

Yes.

> I'm entirely convinced there's a problem, but I don't think your
suggested solution is right.

Ok.

> 
>  Based on my reading of AMD and especially Intel VT-x documentation, the busy 
> bit must be set in the TSS that's loaded into the TR at all times. The busy 
> bit is set on CPU reset, the LTR instruction sets it, any task switch sets 
> it. In other words, there is no way to unset it. VT-x actively prevents 
> loading the guest state if the busy bit in the TR is not set.

I think you are right regarding the documentation. However I think the
actual point is that the tr should not be (re-)loaded into hardware when
coming from REM if it was actually not changed/touched at all. This
would avoid all the hassle completely.

By the way, is there a standard way in VBox (a flag, e.g.) per register
to detect whether it was changed by REM - so that the HM acceleration
part may decide what to write/reload into VMCS/VMCB and what not.

I mean, just comparing the register after a exit and the state short
before resuming HM mode is possible, but nothing what is really
desirable (for various reasons).


>  So the code in VBoxRecompiler.c which clears the busy bit is just plain 
> wrong, and there may be some code in the recompiler (task switch code) that 
> needs adjusting as well. We'll need to fix that.

I see, thanks for taking care.

Alex.

> 
> 
>       Regards,
>          Michal
> 
> ----- Original Message -----
> From: alexander.boettc...@genode-labs.com
> To: michal.neca...@oracle.com
> Cc: vbox-dev@virtualbox.org
> Sent: Monday, March 20, 2017 10:20:00 PM GMT +01:00 Amsterdam / Berlin / Bern 
> / Rome / Stockholm / Vienna
> Subject: Re: [vbox-dev] Question regarding - tr.flags and TSS_BUSY
> 
> Hello,
> 
> 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 [6] 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) [7]. Then the assertion triggers as shown in [3] by the line of
> [8] 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.
> 
> Cheers,
> 
> Alex.
> 
> 
> [0] https://github.com/alex-ab/genode/raw/vbox4_tss_qemu/log.iso
> [1] https://github.com/alex-ab/genode/raw/vbox4_tss_qemu/log_iso.txt
> 
> [2]
> https://github.com/alex-ab/genode/raw/vbox4_tss_qemu/virtualbox_tss_bad.iso
> [3]
> https://github.com/alex-ab/genode/raw/vbox4_tss_qemu/virtualbox_tss_bad.txt
> 
> [4]
> https://github.com/alex-ab/genode/raw/vbox4_tss_qemu/virtualbox_tss_fix.iso
> [5]
> https://github.com/alex-ab/genode/raw/vbox4_tss_qemu/virtualbox_tss_fix.txt
> 
> 
> [6]
> https://github.com/alex-ab/qemu/blob/stable-2.4/target-i386/seg_helper.c#L577
> [7]
> https://github.com/alex-ab/qemu/blob/stable-2.4/target-i386/seg_helper.c#L676
> [8]
> https://github.com/alex-ab/qemu/blob/stable-2.4/target-i386/seg_helper.c#L151
> 
> 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?
>>
>>
>>       Regards,
>>          Michal
>>
>> ----- Original Message -----
>> From: alexander.boettc...@genode-labs.com
>> To: michal.neca...@oracle.com, vbox-dev@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
>>
>> Hello,
>>
>> 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
>> Genode/NOVA.
>>
>>> 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.
>>
>>
>> Cheers,
>>
>> Alex.
>>
> 

-- 
Alexander Boettcher
Genode Labs

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
_______________________________________________
vbox-dev mailing list
vbox-dev@virtualbox.org
https://www.virtualbox.org/mailman/listinfo/vbox-dev

Reply via email to