On Tue, 2007-03-27 at 10:48 +0800, Zhang, Xing Z wrote:
> Hi Kouya:
> I confirmed your patch can solve it. But I think it's a work around
> way.
> Although it can prevent general fault raising which caused by write
> zero to PTA, it also makes SMP windows become to UP during
> installation. ( two vcpus
> SMP windows can work normal due to the value which used to judge
> whether
> cpu wake up successful happen equal to two. Actually, the value is a
> garbage value.)
> The PAL call patch can root fix it, and we have sent out new GFW. So
> I think
> you not need wait.
Hi Kouya, Wing,
I've tested both patches, and this one (return to SAL) seems far more
robust. I configured a 10-way guest, the install only used 2 vCPUs, but
apparently that's normal. When I boot it up for real, it brings 8 vCPUs
online, which is as much as the license I'm using allows for. The PAL
call approach still leave limitations in the number of vCPUs configured
for both install and runtime. When those limitations are exceeded, the
domain panics just as it does today (not a good end user experience).
We also can't fully explain why exporting processors as dual-core
modules makes any difference.
Can this be combined with Tristan's approach for HVM vCPU hotplug
that he's implemented in his GFW? Tristan allows hotplugged vCPUs to
return online, which it appears this one does not. It might take
changes to both the Intel GFW and to Xen to make this work. Thanks,
Alex
--
Alex Williamson HP Open Source & Linux Org.
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
Home