From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NCJGc-0000to-8R for qemu-devel@nongnu.org; Sun, 22 Nov 2009 15:42:42 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NCJGX-0000s9-U0 for qemu-devel@nongnu.org; Sun, 22 Nov 2009 15:42:41 -0500 Received: from [199.232.76.173] (port=58460 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NCJGX-0000s6-Py for qemu-devel@nongnu.org; Sun, 22 Nov 2009 15:42:37 -0500 Received: from mail.gmx.net ([213.165.64.20]:52314) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1NCJGX-000313-2z for qemu-devel@nongnu.org; Sun, 22 Nov 2009 15:42:37 -0500 Message-ID: <74E6EFE7D92346E29A2E321F017E6308@FSCPC> From: "Sebastian Herbszt" References: <20091122140853.GI3193@redhat.com> <20091122172101.GB9880@redhat.com> <38AF5F086DB24529A1D605A0E2414FD0@FSCPC> <20091122195136.GC9880@redhat.com> In-Reply-To: <20091122195136.GC9880@redhat.com> Date: Sun, 22 Nov 2009 21:41:26 +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@koconnor.net, qemu-devel@nongnu.org Gleb Natapov wrote: > On Sun, Nov 22, 2009 at 06:39:16PM +0100, Sebastian Herbszt wrote: >> Gleb Natapov wrote: >> >On Sun, Nov 22, 2009 at 05:51:41PM +0100, Sebastian Herbszt wrote: >> >>Gleb Natapov wrote: >> >>>Microsoft SVVP (Server Virtualization Validation Program) expects >> >>>arbitrary SMBIOS field to have certain values otherwise it fails. >> >>>We all want to make Microsoft happy don't we? So lets put values MS >> >>>expects in there. >> >>> >> >>>Values modified by the patch: >> >>>Type 0: >> >>> Bit 2 of byte 2 must be 1 >> >>>Type 1: >> >>> Manufacturer/product string should not be empty >> >>>Type 3: >> >>> Manufacturer string should not be empty >> >>>Type 4: >> >>> Processor manufacturer should no be empty >> >>> Max/current CPU speed shouldn't be unknown >> >>>Type 16: >> >>> Memory should have error correction. >> >>> >> >>>Signed-off-by: Gleb Natapov >> >>>diff --git a/src/smbios.c b/src/smbios.c >> >>>index f1b43f2..332bb4e 100644 >> >>>--- a/src/smbios.c >> >>>+++ b/src/smbios.c >> >>>@@ -96,7 +96,8 @@ smbios_init_type_0(void *start) >> >>> memset(p->bios_characteristics, 0, 8); >> >>> p->bios_characteristics[0] = 0x08; /* BIOS characteristics not supported */ >> >>> p->bios_characteristics_extension_bytes[0] = 0; >> >>>- p->bios_characteristics_extension_bytes[1] = 0; >> >>>+ /* Enable targeted content distribution. Needed for SVVP */ >> >>>+ p->bios_characteristics_extension_bytes[1] = 4; >> >>> >> >>> if (!qemu_cfg_smbios_load_field(0, offsetof(struct smbios_type_0, >> >>> system_bios_major_release), >> >> >> >>Are the BIOS characteristics extension bytes valid if BIOS characteristics is not supported? >> >I have no idea. SVVP test complains though. >> >> p->bios_characteristics[0] = 0x08; /* BIOS characteristics not supported */ >> >> Can you retest with this line removed? >> > I will, but I don't expect different result. Why should I? I would suggest to remove the line if it still does pass the test. [snip] >> >>>/* Type 4 -- Processor Information */ >> >>>@@ -198,7 +199,7 @@ smbios_init_type_4(void *start, unsigned int cpu_number) >> >>> p->socket_designation_str = 1; >> >>> p->processor_type = 0x03; /* CPU */ >> >>> p->processor_family = 0x01; /* other */ >> >>>- p->processor_manufacturer_str = 0; >> >>>+ p->processor_manufacturer_str = 2; >> >>> >> >>> u32 cpuid_signature, ebx, ecx, cpuid_features; >> >>> cpuid(1, &cpuid_signature, &ebx, &ecx, &cpuid_features); >> >>>@@ -209,8 +210,8 @@ smbios_init_type_4(void *start, unsigned int cpu_number) >> >>> p->voltage = 0; >> >>> p->external_clock = 0; >> >>> >> >>>- p->max_speed = 0; /* unknown */ >> >>>- p->current_speed = 0; /* unknown */ >> >>>+ p->max_speed = 2000; >> >>>+ p->current_speed = 2000; >> >>> >> >>> p->status = 0x41; /* socket populated, CPU enabled */ >> >>> p->processor_upgrade = 0x01; /* other */ >> >>>@@ -221,10 +222,10 @@ smbios_init_type_4(void *start, unsigned int cpu_number) >> >>> >> >>> start += sizeof(struct smbios_type_4); >> >>> >> >>>- memcpy((char *)start, "CPU " "\0" "" "\0" "", 7); >> >>>- ((char *)start)[4] = cpu_number + '0'; >> >>>+ memcpy((char *)start, "CPU \0QEMU\0\0", 12); >> >>>+ ((char *)start)[4] = cpu_number + '0'; >> >>> >> >>>- return start+7; >> >>>+ return start+12; >> >>>} >> >> >> >>Should the manufacturer not depend on the emulated cpu? At least VMware uses the output from >> >>CPUID (GenuineIntel) ; tho my BIOS does just report "Intel". >> >I what it to be something fictional. We support migration from Intel to >> >AMD and back so this info is meaningless in virtualization environment. >> >> Does the system still report "GenuineIntel" if migrated from Intel to AMD host? >> I don't see a problem reporting the emulated cpu vendor, since it's not supposed to change during >> the lifetime of a VM, right? >> > Well, real system don't report cpuid value here why should we? It is > QEMU and not intel or amd manufactured this CPU after all. I don't think this argumentation brings us forward. After all i could argue for stopping using Intels pci vendor id for the pci bridge since they didn't manufactured it either. - Sebastian