Re: [Qemu-devel] [PATCH] target-i386: defer VMEXIT to do_interrupt

[Alexander Boettcher <alexander.boettcher@genode-labs.com>]

On 07.03.2017 15:35, Alex Bennée wrote:
> 
> Paolo Bonzini <pbonzini@redhat.com> writes:
> 
>> Paths through the softmmu code during code generation now need to be audited
>> to check for double locking of tb_lock.  In particular, VMEXIT can take tb_lock
>> through cpu_vmexit -> cpu_x86_update_cr4 -> tlb_flush.
>>
>> To avoid this, split VMEXIT delivery in two parts, similar to what is done with
>> exceptions.  cpu_vmexit only records the VMEXIT exit code and information, and
>> cc->do_interrupt can then deliver it when it is safe to take the lock.
>>
>> Reported-by: Alexander Boettcher <alexander.boettcher@genode-labs.com>
>> Suggested-by: Richard Henderson <rth@twiddle.net>
>> Tested-by: Alexander Boettcher <alexander.boettcher@genode-labs.com>
>> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> 
> Looks good to me. When I ran it against Alexander's test case I got:
> 
>   [init -> log_terminal]
>   [init -> log_terminal] [ 0] CORE:0:0:0 10:2:3:0 [0] AMD Phenom(tm) 9550 Quad-Core Processor
>   [init -> log_terminal] [ 0] Killed EC:0xc002c160 SC:0xc002d100 V:0xd CS:0x1b EIP:0x14455e CR2:0xe0004004 ERR:0x0 (PT not found) Pd::root
> 
> But that could be because I'm running remotely in a terminal environment
> with a null display. I did test against my known good x86 setup and gave
> it some stress and it looks good on that. As long as Alexander is happy
> with his testing I'll snarf this into my series and post today.

That is fine. The GP (0xd) exception will be fixed as soon as the
reorder SVM I/O patch get into qemu master ( I posted it some days ago
with subject "[PATCH± SVM I/O permission bitmap for user-level (ring-3)
code ignored" )

Thanks!

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