From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: 2.6.22 x86_64 : kernel initial decompression hangs on vmware Date: Thu, 09 Aug 2007 23:57:48 +0300 Message-ID: <46BB7FCC.4040509@qumranet.com> References: <46A7E606.4030001@oxeva.fr> <46B4A7E4.4030907@vmware.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <46B4A7E4.4030907-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org To: Zachary Amsden Cc: kvm-devel , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Andi Kleen , Virtualization Mailing List , Jim Mattson , Gabriel Barazer List-Id: virtualization@lists.linuxfoundation.org Zachary Amsden wrote: > > Since I was just involved in the boot decompressor for another bug, I > took a look at this. 2.6.22 switches it to be 64-bit code. VT is > very picky about what state it can run in. Not using VT on Intel > 64-bit hardware cripples performance, running at far below normal > speed, and taking minutes to decompress the kernel, which is nearly > instantaneous otherwise. > > To get back into VT in this case, not only do we need to load FS and > GS, we also need to setup an initial LDT and task. Can you try the > attached patch and see that it does the right thing? > > I've also cc'd the KVM developers, as the same problem will affect > them, and hopefully the same patch will fix it. > We haven't seen any issue with the 2.6.22 boot decompressor. Which of the four (fs, gs, ldt, or tr) were proving problematic and why? ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1765933AbXHIU6G (ORCPT ); Thu, 9 Aug 2007 16:58:06 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756677AbXHIU54 (ORCPT ); Thu, 9 Aug 2007 16:57:56 -0400 Received: from il.qumranet.com ([82.166.9.18]:43390 "EHLO il.qumranet.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755919AbXHIU5z (ORCPT ); Thu, 9 Aug 2007 16:57:55 -0400 Message-ID: <46BB7FCC.4040509@qumranet.com> Date: Thu, 09 Aug 2007 23:57:48 +0300 From: Avi Kivity User-Agent: Thunderbird 2.0.0.5 (X11/20070719) MIME-Version: 1.0 To: Zachary Amsden CC: Gabriel Barazer , Andi Kleen , Jim Mattson , linux-kernel@vger.kernel.org, Virtualization Mailing List , kvm-devel Subject: Re: 2.6.22 x86_64 : kernel initial decompression hangs on vmware References: <46A7E606.4030001@oxeva.fr> <46B4A7E4.4030907@vmware.com> In-Reply-To: <46B4A7E4.4030907@vmware.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Zachary Amsden wrote: > > Since I was just involved in the boot decompressor for another bug, I > took a look at this. 2.6.22 switches it to be 64-bit code. VT is > very picky about what state it can run in. Not using VT on Intel > 64-bit hardware cripples performance, running at far below normal > speed, and taking minutes to decompress the kernel, which is nearly > instantaneous otherwise. > > To get back into VT in this case, not only do we need to load FS and > GS, we also need to setup an initial LDT and task. Can you try the > attached patch and see that it does the right thing? > > I've also cc'd the KVM developers, as the same problem will affect > them, and hopefully the same patch will fix it. > We haven't seen any issue with the 2.6.22 boot decompressor. Which of the four (fs, gs, ldt, or tr) were proving problematic and why?