All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Campbell <ian.campbell@citrix.com>
To: Jim Fehlig <jfehlig@suse.com>, libvir-list@redhat.com
Cc: xen-devel@lists.xen.org
Subject: Re: [PATCH V2] Xen: support maxvcpus in xm and xl config
Date: Wed, 16 Dec 2015 11:09:47 +0000	[thread overview]
Message-ID: <1450264187.4053.32.camel@citrix.com> (raw)
In-Reply-To: <1450260674.16856.233.camel@citrix.com>

On Wed, 2015-12-16 at 10:11 +0000, Ian Campbell wrote:
> On Tue, 2015-12-15 at 15:20 -0700, Jim Fehlig wrote:
> > From: Ian Campbell <ian.campbell@citrix.com>
> > 
> > xend prior to 4.0 understands vcpus as maxvcpus and vcpu_avail
> > as a bit map of which cpus are online (default is all).
> > 
> > xend from 4.0 onwards understands maxvcpus as maxvcpus and
> > vcpus as the number which are online (from 0..N-1). The
> > upstream commit (68a94cf528e6 "xm: Add maxvcpus support")
> > claims that if maxvcpus is omitted then the old behaviour
> > (i.e. obeying vcpu_avail) is retained, but AFAICT it was not,
> > in this case vcpu==maxcpus==online cpus. This is good for us
> > because handling anything else would be fiddly.
> > 
> > This patch changes parsing of the virDomainDef maxvcpus and vcpus
> > entries to use the corresponding 'maxvcpus' and 'vcpus' settings
> > from xm and xl config. It also drops use of the old Xen 3.x
> > 'vcpu_avail' setting.
> > 
> > The change also removes the maxvcpus limit of MAX_VIRT_VCPUS (since
> > maxvcpus is simply a count, not a bit mask), which is particularly
> > crucial on ARM where MAX_VIRT_CPUS == 1 (since all guests are
> > expected to support vcpu placement, and therefore only the boot
> > vcpu's info lives in the shared info page).
> > 
> > Existing tests adjusted accordingly, and new tests added for the
> > 'maxvcpus' setting.
> > 
> > Signed-off-by: Jim Fehlig <jfehlig@suse.com>
> 
> Acked-by: Ian Campbell <Ian.campbell@citrix.com>
> Tested-by: Ian Campbell <Ian.campbell@citrix.com>
> (as far as "domxml-from-native xen-xl" goes, I seem to have another issue
> actually starting a domain on ARM, which I'll investigate...)

Turned out to be a mismatch between my build-time and run-time libxl
versions, fixed by a clean rebuild. So that's a full Tested-by.

I noticed that the newer cmdline= (inplace of root=+extra= etc) wasn't
supported. I'll knock something up.

Ian.

  reply	other threads:[~2015-12-16 11:09 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1450218051-25842-1-git-send-email-jfehlig@suse.com>
2015-12-16 10:11 ` [PATCH V2] Xen: support maxvcpus in xm and xl config Ian Campbell
2015-12-16 11:09   ` Ian Campbell [this message]
2015-12-18 11:47 ` [libvirt] " Michal Privoznik
     [not found] ` <5673F25B.70606@redhat.com>
2015-12-19  1:25   ` Jim Fehlig
2015-12-15 22:20 Jim Fehlig

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=1450264187.4053.32.camel@citrix.com \
    --to=ian.campbell@citrix.com \
    --cc=jfehlig@suse.com \
    --cc=libvir-list@redhat.com \
    --cc=xen-devel@lists.xen.org \
    /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.