All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Sebastian Herbszt" <herbszt@gmx.de>
To: Gleb Natapov <gleb@redhat.com>
Cc: Kevin O'Connor <kevin@koconnor.net>, qemu-devel@nongnu.org
Subject: [Qemu-devel] Re: [PATCH][SEABIOS] Make SMBIOS table pass MS SVVP test
Date: Thu, 26 Nov 2009 22:38:50 +0100	[thread overview]
Message-ID: <1531EE611B76450DAC6F33B93DAC4DB8@FSCPC> (raw)
In-Reply-To: <20091126073933.GU2999@redhat.com>

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

  reply	other threads:[~2009-11-26 21:40 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
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 [this message]
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=1531EE611B76450DAC6F33B93DAC4DB8@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.