RE: [Xen-devel] RE: [PATCH] Allocate vmcs pages when system booting

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

>-----Original Message-----
>From: Jan Beulich [mailto:JBeulich@xxxxxxxxxx]
>Sent: Thursday, March 18, 2010 6:45 PM
>To: Keir Fraser; Jiang, Yunhong
>Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
>Subject: Re: [Xen-devel] RE: [PATCH] Allocate vmcs pages when system booting
>
>>>> Keir Fraser <keir.fraser@xxxxxxxxxxxxx> 15.01.10 11:31 >>>
>>On 15/01/2010 09:30, "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:
>>
>>>>>> "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx> 15.01.10 10:06 >>>
>>>> b) Can we still turn to the original patch, i.e. pre-allocate all VMCS 
>>>> pages
>>>> for all possible CPU?
>>>
>>> I'm generally opposed to pre-allocations, at least as long as all CPUs are
>>> considered 'possible'. Building with a relatively high nr_cpus= setting
>>> and then running on a relatively small system results in (close to)
>>> unacceptable overhead.
>>>
>>> In fact it's really not clear to me why cpu_possible_map must be set to
>>> CPU_MASK_ALL - if Linux has ways to avoid this, Xen should have too.
>>
>>Does Linux manage a good reliable job of cutting down cpu_possible_map? That
>>would save cpu_possible_map in my eyes, if we could do that. Otherwise it is
>>indeed pretty useless now. Either way, I'd like cpu hotplug notifier chains
>>in the 4.1 development window.
>
>Only now got to look into this: Linux simply counts the disabled CPUs
>along with the present ones, plus it allows a command line override to
>the number of CPU slots reserved for hotplug. I just put together
>something similar, partly copying code over from there. Will submit
>post-4.0.
>
>Jan

Jan, thanks for your look on this. Yes, that's explained in kernel's 
"linux-2.6/Documentation/x86/x86_64/cpu-hotplug-spec" . I didn't take the 
assumption that MADT wil always list hot-plugable CPUs.
The reason I take this is because
a) at that time, I thought linux is not the only possible dom0, other OS like 
Solaris or FreeBSD can work as dom0 also in theory, so we'd better work as the 
spec's statement, not according to kernel's implementation, after all, xen is 
HYPERVISOR :-)
b) This statement talks about ACPI 3.0, and AFAIK, the ACPI 4.0 didn't change 
for this requirement still.
c) I didn't realize this VMCS page issue when I working on the patch :$

Of course, I'm not strong against the kernel's method, and your patch is ok for 
me.

Below are kernel's doc:
"Linux/x86-64 supports CPU hotplug now. For various reasons Linux wants to
know in advance of boot time the maximum number of CPUs that could be plugged
into the system. ACPI 3.0 currently has no official way to supply
this information from the firmware to the operating system.
......
For CPU hotplug Linux/x86-64 expects now that any possible future hotpluggable
CPU is already available in the MADT. If the CPU is not available yet
it should have its LAPIC Enabled bit set to 0. Linux will use the number
of disabled LAPICs to compute the maximum number of future CPUs.

.. 
In the worst case the user can overwrite this choice using a command line
option (additional_cpus=...), but it is recommended to supply the correct
number (or a reasonable approximation of it, with erring towards more not less)
in the MADT to avoid manual configuration."

--jyh


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