RE: [Xen-devel] [RFC] Physical hot-add cpus and TSC

["Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>]

>> >Are there any other questionable conditions that might
>> >arise from hot-adding physical CPUs?  For example (my
>> >favorite), are any order>0 allocations required?  Or
>>
>> I don't remember >0 allocation,, will check it when back to office.

Hmm, some >0 order do exists, like per_cpu stack, or per_cpu area. Allocation 
failure should only cause hotplug failure, and should have no side-effect.

>>
>> >what if the hot-added cpu results in mixed generations
>> >(e.g. a Nehalem is added to an all-Westmere system,
>> >where the apps are using AES instructions)?  Anything
>> >else?
>>
>> What will happen if system is booting with mixed generation? For
>> example, when AES is not supported found at AP, will BSP disable the
>> AES?
>
>These were just possible examples.  I think there are probably
>other examples which may cause problems.

We need category these potential issues. The AES is the feature difference, and 
I assume it is same as booting stage.

>
>> Agree that correctness is most important, what I suggested is, let
>> dom0/adminstrator tools to guard the correctness, not hypervisor, to
>> keop the flexibility. Any idea.
>
>And I agree with you that anything that can be done in tools
>should be done in tools instead of the hypervisor.  But requiring
>a physical system administrator to know everything about every
>feature in the underlying physical system, every feature in
>any guest OS, and every app that may or may not run on any VM
>now or in the future -- and then requiring that admin to make
>decisions -- does not IMHO do much to guard correctness.

But what's the difference of tools option and xen option? IMO, even if we want 
to disable CPU hotadd by default, do it in user space tools in release is much 
better than in xen hypervisor. After all, no matter which method used, the 
requirement to physical system admnistrator is same.

And the flexibility of tools brings up several possibility to workaround the 
issue, like utilize cpupool, to limit existing guest to booting-CPUs, while new 
guest to new-added CPUs; or LM exists guest OS and back, to turn fast TSC to 
consistent TSC.
As you said, large data center should documented policies and procedures for 
system administrator.

However, if we disable this through xen option, this hot-add capability can't 
be restored anymore without rebooting.

BTW, Keir, instead of sync the BSP's TSC to new CPU, we can simply keep a TSC 
offset between the two CPUs, this way, we eliminate a write TSC instruction and 
the result should similar to your tsc test code.

>
>Requiring a boot option for hot-add guarantees correctness
>(at the cost of performance only when the boot option is
>specified) and is very simple to implement; that's why I
>am in favor of it.

Thanks
--jyh

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel