Thank you winston! 
we were performing the same experiments yesterday after our regression
*finally* found the same problem... a bit late though, after the patch
was applied to both trees. 
> The best way would be to do the same as the for our ACPI 
> tables -- dynamically generate the CPU entries (LAPIC entries 
> in case of ACPI
> tables) when we know how many VCPUs the guest has been allocated.
>
> This would get rid of multiple statically-compiled rombios 
> images, each of which only differs in CPU info in the MPS 
> table. It could even be hacked up without modifying rombios 
> image -- e.g., hvmloader could scan for and then modify the 
> MPS table to insert secondary-processor entries. It wouldn't 
> be very hard to do.
>
> In any case, I'll revert the earlier patch. Using a MPS table 
> that advertises 8 processors when a guest actually has fewer 
> doesn't seem a very wise idea.
Agreed. Reversion is probably best here for both unstable and
3.0-testing. I'll take a gander at adding the tables dynamically in
hvmloader, and see if I can get a preliminary patch out in a couple of
days - need to test quite a few configurations.
Thanks
Tom
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel