From mboxrd@z Thu Jan 1 00:00:00 1970 From: "H. Peter Anvin" Subject: Re: [RFC] CPUID usage for interaction between Hypervisors and Linux. Date: Wed, 01 Oct 2008 15:46:45 -0700 Message-ID: <48E3FDD5.7040106@zytor.com> References: <1222881242.9381.17.camel@alok-dev1> <48E3B19D.6060905@zytor.com> <1222882431.9381.23.camel@alok-dev1> <48E3BC21.4080803@goop.org> <1222895153.9381.69.camel@alok-dev1> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Jeremy Fitzhardinge , "avi@redhat.com" , Rusty Russell , Gerd Hoffmann , Ingo Molnar , the arch/x86 maintainers , LKML , "Nakajima, Jun" , Daniel Hecht , Zach Amsden , "virtualization@lists.linux-foundation.org" , "kvm@vger.kernel.org" To: akataria@vmware.com Return-path: Received: from terminus.zytor.com ([198.137.202.10]:58536 "EHLO terminus.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752964AbYJAWvA (ORCPT ); Wed, 1 Oct 2008 18:51:00 -0400 In-Reply-To: <1222895153.9381.69.camel@alok-dev1> Sender: kvm-owner@vger.kernel.org List-ID: Alok Kataria wrote: >> No, that's always a terrible idea. Sure, its necessary to deal with >> some backward-compatibility issues, but we should even consider a new >> interface which assumes this kind of thing. We want properly enumerable >> interfaces. > > The reason we still have to do this is because, Microsoft has already > defined a CPUID format which is way different than what you or I are > proposing ( with the current case of 256 leafs being available). And I > doubt they would change the way they deal with it on their OS. > Any proposal that we go with, we will have to export different CPUID > interface from the hypervisor for the 2 OS in question. > > So i think this is something that we anyways will have to do and not > worth binging about in the discussion. No, that's a good hint that what "you and I" are proposing is utterly broken and exactly underscores what I have been stressing about noncompliant hypervisors. All I have seen out of Microsoft only covers CPUID levels 0x40000000 as an vendor identification leaf and 0x40000001 as a "hypervisor identification leaf", but you might have access to other information. This further underscores my belief that using 0x400000xx for anything "standards-based" at all is utterly futile, and that this space should be treated as vendor identification and the rest as vendor-specific. Any hope of creating a standard that's actually usable needs to be outside this space, e.g. in the 0x40SSSSxx space I proposed earlier. -hpa