From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [RFC PATCH v3 0/3] Add segment limit checks to emulator Date: Sun, 25 Jul 2010 21:34:38 +0300 Message-ID: <4C4C83BE.8070406@redhat.com> References: <1278888970-2936-1-git-send-email-m.gamal005@gmail.com> <4C3AB59B.60705@redhat.com> <4C3B14E2.8050404@redhat.com> <20100724154522.GA13246@morn.localdomain> <20100724161630.GA15361@morn.localdomain> <4C4BFC13.8080907@redhat.com> <20100725164246.GB18995@morn.localdomain> <20100725171958.GA22310@morn.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Mohammed Gamal , kvm@vger.kernel.org, seabios@seabios.org To: "Kevin O'Connor" Return-path: Received: from mx1.redhat.com ([209.132.183.28]:65051 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751439Ab0GYSe5 (ORCPT ); Sun, 25 Jul 2010 14:34:57 -0400 In-Reply-To: <20100725171958.GA22310@morn.localdomain> Sender: kvm-owner@vger.kernel.org List-ID: On 07/25/2010 08:19 PM, Kevin O'Connor wrote: > On Sun, Jul 25, 2010 at 12:42:46PM -0400, Kevin O'Connor wrote: >> On Sun, Jul 25, 2010 at 11:55:47AM +0300, Avi Kivity wrote: >>> What conditions are needed to trigger this path? This can't occur >>> under normal operation, since it will fail badly with kvm on Intel. >> It's called on every boot. I've personally only tested kvm on amd, >> but I'd have to assume something must be allowing this to work on >> intel. > BTW, the transition16big code does: > > ljmpl $SEG32_MODE16BIG_CS, $(0xf0000 + 1f) > > .code16gcc > 1: > // Disable protected mode > movl %cr0, %eax > andl $~CR0_PE, %eax > movl %eax, %cr0 > > // far jump to flush CPU queue after transition to real mode > ljmpw $0xf000, $2f > 2: > > Only the ljmpw is in big real mode with a code address>64K - the > "Disable protected mode" code is technically in 16bit protected mode. > I'm not sure if that helps explain why it works. What happens is kvm enters real mode with cs.limit=0xffff, the guest #GPs due to segment limit violation, and enters the emulator, which emulates the far jump correctly. So this works, and will continue to work even after we fix limit checking. It's still cleaner IMO to use normal code segments. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.