On 07.03.2017 15:35, Alex Bennée wrote: > > Paolo Bonzini <[email protected]> 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 <[email protected]> >> Suggested-by: Richard Henderson <[email protected]> >> Tested-by: Alexander Boettcher <[email protected]> >> Signed-off-by: Paolo Bonzini <[email protected]> > > 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
