On 11/04/2009 03:40 PM, Gleb Natapov wrote:
On Tue, Nov 03, 2009 at 10:30:12PM -0500, Kevin O'Connor wrote:
On Tue, Nov 03, 2009 at 04:31:32PM +0100, Magnus Christensson wrote:
I'm attaching patches for seabios to make it work on the Virtutech Simics x86-440bx model. Please let me know if there is some other list that is preferred for seabios patches.
Patches 1-6 and 9 are not really related to the Virtutech model at all, so those would be prime candidates to be included in the mainline version.
l> Thanks Magnus.
Gleb I'm not sure if you're on the coreboot mailing list - can you take a look at these patches as well? A URL is at:
Can I get them in a mbox format somewhere? Want to tested them to be sure. From review: 1: OK
2: What is the reason for this? x86info --mptable on my 4 core AMD shows MP Table: # APIC ID Version State Family Model Step Flags # 0 0x10 BSP, usable 16 4 1 0x178bfbff # 1 0x10 AP, usable 16 4 1 0x178bfbff # 2 0x10 AP, usable 16 4 1 0x178bfbff # 3 0x10 AP, usable 16 4 1 0x178bfbff
I can think of two reasons for only listing one CPU per package. The first would be performance, in that the OS needs to be aware of multi-threading in order not to slow down high priority tasks with stuff that is usually free when running on multiple processors (like spinlocks). The second reason would be that logical CPUs in the same package share some MSRs, and an OS that isn't aware of that may cease to work in such an environment.
Related link:
http://software.intel.com/en-us/articles/hyper-threading-implications-and-se...
3: And why is this? My mptable spec (from 1997) says that apic id is 8 bit and x86info --mptable on my Intel with 16 logical cpus shows: MP Table: # APIC ID Version State Family Model Step Flags # 0 0x15 BSP, usable 6 10 5 0x0381 # 16 0x15 AP, usable 6 10 5 0x0381 Interesting that on Intel only one entry per physical package.
I don't really remember the reason for that limit. I simply added stuff from our BIOS to SeaBIOS until they generated identical MPS tables. Feel free to ignore this patch.
4: I am not sure why we want to make it faster (waiting anyway) but OK.
Virtutech Simics is often run with scripted input, and time is then compressed whenever possible to boost overall performance.
5: OK. Wanted to add this by myself for a long time. We configure LINT0 inside KVM now, but this is BIOS job.
6: OK.
7: Don't like VIRTUTECH_IRQ0_OVERRIDE checking inside qemu_cfg_irq0_override(). What about creating irq0_override() in generic code that will call qemu_cfg_irq0_override() if needed. Setting VIRTUTECH_IRQ0_OVERRIDE to 1 by default is not a welcomed too :)
I'll add a QEMU compatible paravirt device for Simics, and then we can live without this patch.
8: Do not set VIRTUTECH_PC_SHADOW to 1 by default please. Otherwise the code is not used by qemu so OK.
9: OK
10: USE_CMOS_BIOS_SMP_COUNT default to 1
I'm attaching the (modified) patches.
M.