qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: [PATCH][SEABIOS] Make SMBIOS table pass MS SVVP test


From: Sebastian Herbszt
Subject: [Qemu-devel] Re: [PATCH][SEABIOS] Make SMBIOS table pass MS SVVP test
Date: Wed, 25 Nov 2009 21:09:19 +0100

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.
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?

- Sebastian





reply via email to

[Prev in Thread] Current Thread [Next in Thread]