This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: Jan Beulich <JBeulich@xxxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Subject: RE: [Xen-devel] RE: [PATCH] Allocate vmcs pages when system booting
From: "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>
Date: Fri, 19 Mar 2010 10:17:02 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 18 Mar 2010 19:18:38 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4BA212510200007800035AF5@xxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4B5043B8020000780002A2E9@xxxxxxxxxxxxxxxxxx> <C775F48B.66D1%keir.fraser@xxxxxxxxxxxxx> <4BA212510200007800035AF5@xxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcrGiB2soNxrlRoxQUKlwaPu0FDp1wAfxmAw
Thread-topic: [Xen-devel] RE: [PATCH] Allocate vmcs pages when system booting

>-----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

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 
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 

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."


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>