From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NDYx5-0001fm-SQ for qemu-devel@nongnu.org; Thu, 26 Nov 2009 02:39:44 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NDYx0-0001c7-H6 for qemu-devel@nongnu.org; Thu, 26 Nov 2009 02:39:42 -0500 Received: from [199.232.76.173] (port=36868 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NDYx0-0001bF-24 for qemu-devel@nongnu.org; Thu, 26 Nov 2009 02:39:38 -0500 Received: from mx1.redhat.com ([209.132.183.28]:51167) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NDYwz-0002Q7-Ej for qemu-devel@nongnu.org; Thu, 26 Nov 2009 02:39:37 -0500 Date: Thu, 26 Nov 2009 09:39:33 +0200 From: Gleb Natapov Message-ID: <20091126073933.GU2999@redhat.com> References: <20091122172101.GB9880@redhat.com> <38AF5F086DB24529A1D605A0E2414FD0@FSCPC> <20091122195136.GC9880@redhat.com> <74E6EFE7D92346E29A2E321F017E6308@FSCPC> <20091123072823.GB2999@redhat.com> <1F775774A6D54955836164CA63C6BFBA@FSCPC> <20091123183041.GB10115@redhat.com> <20091124155702.GC17606@morn.localdomain> <20091124165901.GK2999@redhat.com> <7E2D4427B49644BABD061B0D25E8B952@FSCPC> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7E2D4427B49644BABD061B0D25E8B952@FSCPC> Subject: [Qemu-devel] Re: [PATCH][SEABIOS] Make SMBIOS table pass MS SVVP test List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Sebastian Herbszt Cc: Kevin O'Connor , qemu-devel@nongnu.org On Wed, Nov 25, 2009 at 09:09:19PM +0100, Sebastian Herbszt wrote: > Gleb Natapov wrote: > >On Tue, Nov 24, 2009 at 10:57:02AM -0500, Kevin O'Connor wrote: > >> > >>That said, I think SeaBIOS should autodetect any values where that's > >>feasible. So, for example, if the cpu identification is available via > >>cpuid, then I think that should be used. However, for example, if cpu > >>model isn't available anywhere, then I think hardcoding something is > >>okay. > >It is used already where appropriate. To fill processor_id field in type > >4 table. CPU manufacturer is different issue. CPU a guest is running on is > >not manufactured by Intel or AMD, it is emulated by QEMU. > > I am still wondering why you're against using the vendor reported by CPUID. I am still wondering why you want this :) But let me ask you a question: You are running some program inside QEMU and you encounter a bug. Some instruction does not update eflags like it should and program fails. Do you complain to a) AMD b) Intel c) QEMU mailing list. If your answer is (c), then I don't see how you can propose to put something else then QEMU in manufacturer field. > The cross vendor host cpu migration doesn't seem to be a sound reason, because > the cpu in the guest is emulated and has no relationship to the host cpu. > If i specify "-cpu phenom", i end up with an AMD cpu. Since noone but AMD > produces this cpu it seems only reasonable to advertise the vendor as AMD. > > >>> > >>>>>>>- p->max_speed = 0; /* unknown */ > >>> > >>>>>>>- p->current_speed = 0; /* unknown */ > >>> > >>>>>>>+ p->max_speed = 2000; > >>> > >>>>>>>+ p->current_speed = 2000; > >> > >>SeaBIOS detects the current Mhz - see calibrate_tsc() in src/clock.c. > >> > >How accurate is it? What if I boot 100 guests on 16 cpu host > >simultaneously? Not uncommon scenario. Those field really have no > >meaning in virtualization environment. I'd rather have predictable > >values there from boot to boot. Who know what Windows may use them for. > > Speaking of not knowing what an OS or application might do with values in the > SMBIOS table. Doesn't the same argument apply to the cpu vendor? > I am concern with SMBIOS table be different on each boot, not what information is stored in those fields. CPU manufacturer is free form string. I have computers that have "Intel" there, others have "Intel(R) Corporation". As long as it consistent from boot to boot it is OK IMO. -- Gleb.