From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alok Kataria Subject: Re: [RFC] CPUID usage for interaction between Hypervisors and Linux. Date: Wed, 01 Oct 2008 14:05:53 -0700 Message-ID: <1222895153.9381.69.camel@alok-dev1> References: <1222881242.9381.17.camel@alok-dev1> <48E3B19D.6060905@zytor.com> <1222882431.9381.23.camel@alok-dev1> <48E3BC21.4080803@goop.org> Reply-To: akataria@vmware.com Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: "H. Peter Anvin" , "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: Jeremy Fitzhardinge Return-path: Received: from smtp-outbound-2.vmware.com ([65.115.85.73]:58614 "EHLO smtp-outbound-2.vmware.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753231AbYJAVF4 (ORCPT ); Wed, 1 Oct 2008 17:05:56 -0400 In-Reply-To: <48E3BC21.4080803@goop.org> Sender: kvm-owner@vger.kernel.org List-ID: On Wed, 2008-10-01 at 11:06 -0700, Jeremy Fitzhardinge wrote: > Alok Kataria wrote: > > Its not a user who has to do anything special here. > > There are *intelligent* VM developers out there who can export a > > different CPUid interface depending on the guest OS type. And this is > > what most of the hypervisors do (not necessarily for CPUID, but for > > other things right now). > > > > 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. -- Alok > J