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
next prev parent 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 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).