From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: VMX and save/restore guest in virtual-8086 mode Date: Thu, 08 Apr 2010 10:29:53 +0300 Message-ID: <4BBD85F1.50900@redhat.com> References: <20100407202400.GA29595@amt.cnet> <4BBCEF34.8000607@redhat.com> <4BBD8453.2030405@siemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Marcelo Tosatti , kvm , Gleb Natapov To: Jan Kiszka Return-path: Received: from mx1.redhat.com ([209.132.183.28]:28629 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758496Ab0DHH36 (ORCPT ); Thu, 8 Apr 2010 03:29:58 -0400 In-Reply-To: <4BBD8453.2030405@siemens.com> Sender: kvm-owner@vger.kernel.org List-ID: 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. >>> 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. >>> - 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. -- error compiling committee.c: too many arguments to function