WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH] make x86_64 vcpu hotplug work like i386

To: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] make x86_64 vcpu hotplug work like i386
From: Ryan Grimm <grimm@xxxxxxxxxx>
Date: Fri, 17 Feb 2006 14:05:19 -0600
Cc: Xen Devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 17 Feb 2006 20:19:07 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <990e446ad64e33243bd24c09b6eaba0b@xxxxxxxxxxxx>
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20060208214331.GA827@xxxxxxxxxxxxxxxxxxxxx> <990e446ad64e33243bd24c09b6eaba0b@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.6+20040907i
On Thu, Feb 16, 2006 at 11:49:00AM +0000, Keir Fraser wrote:
> 
> On 15 Feb 2006, at 23:04, Ryan Grimm wrote:
> 
> >This patch allows a domain's vcpus to increase beyond the max (up to
> >CONFIG_NR_CPUS) set at creation time by making 3 changes:
> 
> I'd prefer to keep the current Xen mechanisms, but extend xend and/or 
> config file formats so that we can distinguish max_vcpus from 
> initial_vcpus. Currently the two values are conflated. Then you can set 
> max_vcpus as high as you like, but xenstore will tell the guest how 
> many CPUs to bring up during boot.

One drawback of this is that the store is not up for dom0's creation.
So, i guess the two values could not apply to dom0?
 
> If we want a 'hard limit' check in Xen (kind of like we have a 
> per-domain memory limit) to ensure that guests do not sneakily bring up 
> CPUs that we didn't ask them to, then we can add that but it's an 
> orthogonal change (i.e., different patch) to what you are trying to do 
> here.

So, you're saying that the config file could specify max_vcpus to say,
8, and initial to say, 2.  Then, there would need to be another value
inside of XEN, that would be the hard limit.  This could be enforced via
another dom0_op, which sets the hard limit, and a vcpu_op, which would
tell the domain whether it was allowed to bring up another cpu.

How does this approach sound to you?

I think the benefits of the approach that I submitted are that it makes
a very small change in XEN and brings smpboot.c to more closely mirror
the way linux does hot add, in terms of the mappings.  Is it the use of
DOM0_MAX_VCPUS after domain creation that you find particularly ugly? 

Thanks,
Ryan

sorry for the resent, forgot to CC xen-devel earlier
> 
>  -- Keir
> 

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

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