All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ryan Grimm <grimm@us.ibm.com>
To: Keir Fraser <Keir.Fraser@cl.cam.ac.uk>
Cc: Xen Devel <xen-devel@lists.xensource.com>
Subject: Re: [PATCH] make x86_64 vcpu hotplug work like i386
Date: Fri, 17 Feb 2006 14:05:19 -0600	[thread overview]
Message-ID: <20060217200519.GA18025@localhost.localdomain> (raw)
In-Reply-To: <990e446ad64e33243bd24c09b6eaba0b@cl.cam.ac.uk>

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
> 

      reply	other threads:[~2006-02-17 20:05 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-08 21:43 [PATCH] make x86_64 vcpu hotplug work like i386 Ryan Grimm
2006-02-08 23:29 ` Keir Fraser
2006-02-17 20:05   ` Ryan Grimm [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060217200519.GA18025@localhost.localdomain \
    --to=grimm@us.ibm.com \
    --cc=Keir.Fraser@cl.cam.ac.uk \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.