From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: KVM Processor cache size Date: Tue, 03 Aug 2010 08:41:35 +0300 Message-ID: <4C57AC0F.3070909@redhat.com> References: <4C56BF6F.9040402@amd.com> <4C56C353.7020607@redhat.com> <4C5745BC.30908@codemonkey.ws> <4C574CC3.2040703@amd.com> <4C575776.30106@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Andre Przywara , Ricardo Martins , "kvm@vger.kernel.org" To: Anthony Liguori Return-path: Received: from mx1.redhat.com ([209.132.183.28]:49424 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754894Ab0HCFlq (ORCPT ); Tue, 3 Aug 2010 01:41:46 -0400 In-Reply-To: <4C575776.30106@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: On 08/03/2010 02:40 AM, Anthony Liguori wrote: > > Yes, but virtualization is not supposed to expose the underlying > hardware. The vendor_id bit is a harder problem that I'm willing to > ignore in this discussion. I understand why we have to do this today. Today and forever... unless one of the processor vendors starts supporting the other's fast system call instructions on all modes. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.