Avi Kivity wrote: > On 04/08/2010 10:22 AM, Jan Kiszka wrote: >> Avi Kivity wrote: >> >>> On 04/07/2010 11:24 PM, Marcelo Tosatti wrote: >>> >>>> During initialization, WinXP.32 switches to virtual-8086 mode, with >>>> paging enabled, to use VGABIOS functions. >>>> >>>> Since enter_pmode unconditionally clears IOPL and VM bits in RFLAGS >>>> >>>> flags = vmcs_readl(GUEST_RFLAGS); >>>> flags&= ~(X86_EFLAGS_IOPL | X86_EFLAGS_VM); >>>> flags |= (vmx->rmode.save_iopl<< IOPL_SHIFT); >>>> vmcs_writel(GUEST_RFLAGS, flags); >>>> >>>> >>>> >>> Looks like KVM_SET_REGS should write rmode.save_iopl (and a new save_vm)? >>> >> Just like we manipulate the flags for guest debugging in the >> set/get_rflags vendor handlers, the same should happen for IOPL and VM. >> This is no business of enter_pmode/rmode. >> > > This is vendor specific code, and it isn't manipulating guest values, > only host values (->set_rflags() is called when the guest value changes, > which isn't happening here). Of course some refactoring will be helpful > here. Actually, the bug is that enter_pmode/rmode update save_iopl (and that no one saves the VM bit). That should happen in vmx_set_rflags to also keep track of changes _while_ we are in rmode. enter_rmode/pmode should just trigger a set_rflags to update things. And vmx_get_rflags must properly inject the saved flags instead of masking them out. > >>>> The following patch fixes it, but it has some drawbacks: >>>> >>>> - cpu_synchronize_state+writeback is noticeably slow with tpr patching, >>>> this makes it slower. >>>> >>>> >>> Isn't it a very rare event? >>> >> It has to be - otherwise the decision to go for full sync and individual >> get/set IOCTL would have been wrong. What happens during tpr patching? >> >> > > tpr patching listens for instructions which access the tpr and patches > them to a call instruction (targeting some hacky code in the bios). > Since there are a limited number of such instructions (20-30 IIRC) you > expect tpr patching to happen very rarely. Then I wonder why it is noticeable. > >>>> - Its a fugly workaround. >>>> >>>> >>> True. >>> >>> >> Still likely the way to go for old kernels. >> >> > > It's a bugfix that can go into -stable and supported distribution kernels. Well, would be happy to throw out tones of workaround based on this approach. :) Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- 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
