On Thu, Jan 03, 2013 at 10:11:53AM +0200, Gleb Natapov wrote: > > FreeBSD 9.1 with -smp 2. > I cannot reproduce. I do see boot failure on the next branch with 9.[01] > 64 bit -smp 2 here, but it is caused but segment registers been all > incorrect on a secondary vcpu and this patch does not help. Applying > http://comments.gmane.org/gmane.comp.emulators.kvm.devel/102593 fixes > it. > > > > > > > > > The question is how does it happen that we enter real mode while cache > > > > > is set to 3. It should never be 3 during boot since boot process never > > > > > enters the userspace. > > > > > > > > Its transition _to_ real mode (from protected). > > > But in protected mode CPL should be 0 during boot. > > > > BTX (FreeBSD's bootloader) does: > > > > http://people.freebsd.org/~jhb/docs/loader.txt. > Crazy. Regardless, I think your patch is correct and the current code > that uses cpl cache during emulation is wrong and it remains wrong even > after your patch. What if last time cpl cache was updated was while vcpu > ran in cpl 3? Commit message says that it tries to fix the case when > CS.selector&3 != 0 during transition to protected mode, but this can be > fixed by setting cpl cache to 0 in vmx_set_cr0() instead of clearing it. Yes, i suppose so, can be done by a separatch patch, though. > Two things about the patch itself. Get rid of __vmx_get_cpl() and call > to vmx_read_guest_seg_selector() directly from vmx_get_cpl() and drop > __clear_bit(VCPU_EXREG_CPL) from vmx_set_rflags() and vmx_set_cr0() > since vmx->cpl no longer depends on rflags and cr0. You still want to invalidate vmx->cpl cache on cr0 writes: think protected -> real -> protected transition. And as for EFLAGS, agreed. Sending new patch. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
