From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NDm4P-0000BI-UT for qemu-devel@nongnu.org; Thu, 26 Nov 2009 16:40:09 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NDm4L-00009L-Sc for qemu-devel@nongnu.org; Thu, 26 Nov 2009 16:40:09 -0500 Received: from [199.232.76.173] (port=57850 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NDm4L-000099-Mm for qemu-devel@nongnu.org; Thu, 26 Nov 2009 16:40:05 -0500 Received: from mail.gmx.net ([213.165.64.20]:36112) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1NDm4K-0007pM-Vg for qemu-devel@nongnu.org; Thu, 26 Nov 2009 16:40:05 -0500 Message-ID: <1531EE611B76450DAC6F33B93DAC4DB8@FSCPC> From: "Sebastian Herbszt" 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> <20091126073933.GU2999@redhat.com> In-Reply-To: <20091126073933.GU2999@redhat.com> Date: Thu, 26 Nov 2009 22:38:50 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit 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: Gleb Natapov Cc: Kevin O'Connor , qemu-devel@nongnu.org Gleb Natapov wrote: > 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. Since i know i run the program inside QEMU my answer has to be (c). On the other hand the competition doesn't put "VMware" there. >> 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. Then i must admit i understood your "Who know what Windows may use them for" statement different. - Sebastian