From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: catch vmentry failure (was enable gfxboot on VMX) Date: Sun, 02 Mar 2008 19:15:32 +0200 Message-ID: <47CAE0B4.3000400@qumranet.com> References: <47B53B7D.8050209@csgraf.de> <47B597FF.7030304@qumranet.com> <5869160F-A202-4092-9A44-1D65058E188D@csgraf.de> <47B6A780.4090402@qumranet.com> <38713C47-8F04-404A-A3CF-51BDCE1E9999@csgraf.de> <20080218101702.15054d4d@frecb000711> <960FE9EB-B82F-40FF-B8C1-8B053DD7259C@csgraf.de> <7FBF7BE1-4B08-4DB8-B96B-9EE45AF74B32@csgraf.de> <20080229153446.1fdead94@frecb000711.frec.bull.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel , Alexander Graf To: Guillaume Thouvenin Return-path: In-Reply-To: <20080229153446.1fdead94@frecb000711.frec.bull.fr> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces@lists.sourceforge.net Errors-To: kvm-devel-bounces@lists.sourceforge.net List-Id: kvm.vger.kernel.org Guillaume Thouvenin wrote: > On Mon, 18 Feb 2008 10:39:31 +0100 > Alexander Graf wrote: > > > >>> So if you want to see a VMentry failure, just remove the SS patching >>> and you'll see one. My guess would be that you see a lot of problems >>> with otherwise working code too then, though, as SS can be anything in >>> that state. >>> > > So I made some tests and you were right, removing the SS patching > showed VM entry failure but it also generated lots of problems. Thus I > tried to modify a little bit the code and with the following patch (see > the end of the email) I can detect VM Entry failures without generating > other problems. It works when you use a distribution that is > "big-real-mode free". I pasted the patch just to show the idea. > > It's interesting because we can continue to use the virtual mode for the > majority of distribution and we can detect when a VM entry failure is > detected it means that we need to switch from virtual mode to full real > mode emulation. Such failure is caught in handle_vmentry_failure() when > patch applied. If it's doable, the next step is the modification of the > SS segment selector to succeed the vm-entry and the switch from virtual > mode to a real mode emulation that could be done in > handle_vmentry_failure(). Does it make sense? > > Yes. An alternative (useful if a failed vmentry corrupts the guest state) is to check all register state when switching modes. > - > + fix_rmode_seg(VCPU_SREG_CS, &vcpu->arch.rmode.cs); > fix_rmode_seg(VCPU_SREG_ES, &vcpu->arch.rmode.es); > fix_rmode_seg(VCPU_SREG_DS, &vcpu->arch.rmode.ds); > fix_rmode_seg(VCPU_SREG_GS, &vcpu->arch.rmode.gs); > fix_rmode_seg(VCPU_SREG_FS, &vcpu->arch.rmode.fs); > + fix_rmode_seg(VCPU_SREG_SS, &vcpu->arch.rmode.ss); > Ideally you wouldn't call fix_rmode_seg() at all. The guest will emulate until such time as the segments are valid for v8086, for example when the guest reloads them itself. > + switch (basic_exit_reason) { > + case EXIT_REASON_INVALID_GUEST_STATE: > + printk("caused by invalid guest state (%ld).\n", exit_qualification); > + /* At this point we need to modify SS selector to pass vmentry test. > + * This modification prevent the usage of virtual mode to emulate real > + * mode so we need to pass in big real mode emulation > + * with somehting like: > + * vcpu->arch.rmode.emulate = 1 > Note you might need to emulate in protected mode as well, for a small part of the switch, for similar reasons. -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/