From: "Sebastian Herbszt" <herbszt@gmx.de>
To: Gleb Natapov <gleb@redhat.com>
Cc: kevin@koconnor.net, qemu-devel@nongnu.org
Subject: [Qemu-devel] Re: [PATCH][SEABIOS] Make SMBIOS table pass MS SVVP test
Date: Mon, 23 Nov 2009 19:48:20 +0100 [thread overview]
Message-ID: <516EF1CFDCB04E4284C90F99AE54A78F@FSCPC> (raw)
In-Reply-To: <20091123183041.GB10115@redhat.com>
Gleb Natapov wrote:
> On Mon, Nov 23, 2009 at 07:15:55PM +0100, Sebastian Herbszt wrote:
>> Gleb Natapov wrote:
>> >On Sun, Nov 22, 2009 at 09:41:26PM +0100, Sebastian Herbszt wrote:
>> >>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 <gleb@redhat.com>
>> >>>>>>>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.
>> >>
>> >As a different patch. Also may be putting real info there instead of
>> >just deleting the line?
>>
>> Ok - sounds good if bios_characteristics gets proper system based values.
>>
> Kevin can you help here. I can send a patch, but I am not sure I know
> everything SeaBIOS supports.
seabios needs to check the system it runs on and then build the value, e.g. ISA is always (?)
supported, but pci only if a pci bridge is found. Kevin should be able to provide a common
base value tho (APM, Boot from CD is supported, EDD is supported, etc.).
>> >>[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.
>> >>
>> >pci ids are different in that they are used to find driver for a device.
>> >If there was a field in PCI config space to store device manufacturer
>> >name it would be reasonable to put "QEMU" there.
>> >
>> >This SMBIOS field describe CPU manufacturer and serves only informational
>> >purpose. Look at /proc/cpuinfo on qemu VM. The model name reported there
>> >is "QEMU Virtual CPU version 0.9.1" not some real value.
>>
>> Actually mine has
>>
>> vendor_id: GenuineIntel
>> model_name: Pentium II (Klamath)
>>
> How you run it? With -cpu pentium? I use default one (qemu64 I think).
I also use the default one (i386-softmmu target). Looking at target-i386/helper.c the following
cpu types provide real values: phenom, core2duo, coreduo, 486, pentium, pentium2, pentium3, n270.
If you use qemu64 you get vendor AMD and the model_id you mentioned above.
>> Might be different on KVM tho (or if you specify -cpu). Beside if seabios is used with coreboot on a real
>> system the cpu vendor is not QEMU; nor is it on Bochs.
>>
> Yes, coreboot should specify real CPU manufacturer.
What about using the vendor provided by CPUID, so it displays the correct value on coreboot and others, and
change qemu cpus to a different vendor string like padded QEMU or something. Currently qemu64 uses AMD,
kvm64 and qemu32 Intel.
- Sebastian
next prev parent reply other threads:[~2009-11-23 18:49 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-22 14:08 [Qemu-devel] [PATCH][SEABIOS] Make SMBIOS table pass MS SVVP test Gleb Natapov
2009-11-22 16:51 ` [Qemu-devel] " Sebastian Herbszt
2009-11-22 17:21 ` Gleb Natapov
2009-11-22 17:39 ` Sebastian Herbszt
2009-11-22 19:51 ` Gleb Natapov
2009-11-22 20:41 ` Sebastian Herbszt
2009-11-23 7:28 ` Gleb Natapov
2009-11-23 18:15 ` Sebastian Herbszt
2009-11-23 18:30 ` Gleb Natapov
2009-11-23 18:48 ` Sebastian Herbszt [this message]
2009-11-23 19:39 ` Gleb Natapov
2009-11-24 8:18 ` Gleb Natapov
2009-11-24 15:57 ` Kevin O'Connor
2009-11-24 16:59 ` Gleb Natapov
2009-11-24 17:53 ` Kevin O'Connor
2009-11-24 18:41 ` Gleb Natapov
2009-11-24 20:30 ` Kevin O'Connor
2009-11-25 20:09 ` Sebastian Herbszt
2009-11-26 7:39 ` Gleb Natapov
2009-11-26 21:38 ` Sebastian Herbszt
2009-11-22 19:58 ` Yaniv Kaul
2009-11-22 23:57 ` Carl-Daniel Hailfinger
2009-11-23 6:28 ` Gleb Natapov
2009-11-23 18:02 ` Sebastian Herbszt
2009-11-23 11:56 ` Gleb Natapov
2009-11-22 17:07 ` Kevin O'Connor
2009-11-23 11:08 ` Gleb Natapov
2009-11-24 14:40 ` Kevin O'Connor
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=516EF1CFDCB04E4284C90F99AE54A78F@FSCPC \
--to=herbszt@gmx.de \
--cc=gleb@redhat.com \
--cc=kevin@koconnor.net \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).