qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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: Sun, 22 Nov 2009 21:41:26 +0100	[thread overview]
Message-ID: <74E6EFE7D92346E29A2E321F017E6308@FSCPC> (raw)
In-Reply-To: <20091122195136.GC9880@redhat.com>

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.

[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

  reply	other threads:[~2009-11-22 20:42 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 [this message]
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
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=74E6EFE7D92346E29A2E321F017E6308@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).