From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754364AbYIYW21 (ORCPT ); Thu, 25 Sep 2008 18:28:27 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753707AbYIYW14 (ORCPT ); Thu, 25 Sep 2008 18:27:56 -0400 Received: from terminus.zytor.com ([198.137.202.10]:53991 "EHLO terminus.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753029AbYIYW1y (ORCPT ); Thu, 25 Sep 2008 18:27:54 -0400 Message-ID: <48DC105D.9050803@zytor.com> Date: Thu, 25 Sep 2008 15:27:41 -0700 From: "H. Peter Anvin" User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Zachary Amsden CC: Alok Kataria , Alok kataria , Ingo Molnar , Yan Li , "linux-kernel@vger.kernel.org" , "joerg.roedel@amd.com" , "rjmaomao@gmail.com" , Yinghai Lu , Thomas Gleixner , Daniel Hecht Subject: Re: [PATCH 1/2] VMware detection support for x86 and x86-64 References: <20080221115452.GB13948@elte.hu> <20080907234510.GA24133@yantp.cn.ibm.com> <20080908140423.GG11993@elte.hu> <35f686220809241928k3669e30bi8a98b440443c4bff@mail.gmail.com> <48DB15DB.8040501@zytor.com> <1222317978.23524.117.camel@alok-dev1> <48DB1984.8020704@zytor.com> <1222318928.23524.121.camel@alok-dev1> <48DB1BCE.2070106@zytor.com> <1222320201.23524.135.camel@alok-dev1> <1222375694.27056.179.camel@bodhitayantram.eng.vmware.com> <48DC09D9.7040204@zytor.com> <1222381254.27056.194.camel@bodhitayantram.eng.vmware.com> In-Reply-To: <1222381254.27056.194.camel@bodhitayantram.eng.vmware.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Zachary Amsden wrote: > On Thu, 2008-09-25 at 14:59 -0700, H. Peter Anvin wrote: > >> However, it is the particular use of this for detection use that is >> utterly damning. Using random I/O port probes for hardware detect >> should have disappeared in the early 1990's, and it's really disturbing >> that virtualization vendors -- not just VMWare -- are, in effect, >> re-making all the mistakes hardware vendors did in the 1980's. > > It's not disturbing, it's expected. Re-using old broken solutions happens all the time, they can be perfectly valid in some contexts. The problem is that they tend to live on and evolve into a larger context where they break again. Surely we can do better, but how to do that isn't always clear-cut. DMI is a pretty good standard for this, but it still doesn't solve the problem in all contexts (userspace apps). > This, of course, is what CPUID is for. -hpa