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 11:05:56 +0300 Message-ID: <4BBD8E64.4070106@redhat.com> References: <20100407202400.GA29595@amt.cnet> <4BBCEF34.8000607@redhat.com> <4BBD8453.2030405@siemens.com> <4BBD85F1.50900@redhat.com> <4BBD8BBB.3060308@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]:40572 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751969Ab0DHIF7 (ORCPT ); Thu, 8 Apr 2010 04:05:59 -0400 In-Reply-To: <4BBD8BBB.3060308@siemens.com> Sender: kvm-owner@vger.kernel.org List-ID: On 04/08/2010 10:54 AM, Jan Kiszka wrote: > > >>>> 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. Exactly - that's what I suggested above. > enter_rmode/pmode should > just trigger a set_rflags to update things. Not what I had in mind, but a valid implementation. > And vmx_get_rflags must > properly inject the saved flags instead of masking them out. > Yes. No one ever bothers to play with iopl in real mode, so we never noticed this. We do this for cr0 for example. >> 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. :) > And I'll be happy to apply such patches. Just ensure that 2.6.32.y and above have the fixes so we don't introduce regressions (I think most workarounds are a lot older). -- error compiling committee.c: too many arguments to function