xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Wei Liu <wei.liu2@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Wei Liu <wei.liu2@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	Anthony PERARD <anthony.perard@citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: "xl vcpu-set" not persistent across reboot?
Date: Tue, 7 Jun 2016 09:30:21 +0100	[thread overview]
Message-ID: <20160607083021.GD25922@citrix.com> (raw)
In-Reply-To: <5755B434.3070203@citrix.com>

On Mon, Jun 06, 2016 at 06:34:44PM +0100, Andrew Cooper wrote:
> On 06/06/16 18:20, Wei Liu wrote:
> > Use Stefano's new email address
> >
> > On Mon, Jun 06, 2016 at 06:18:06PM +0100, Wei Liu wrote:
> >> On Fri, Jun 03, 2016 at 05:35:20PM +0100, Wei Liu wrote:
> >>> On Fri, Jun 03, 2016 at 08:42:11AM -0600, Jan Beulich wrote:
> >>>>>>> On 03.06.16 at 15:41, <wei.liu2@citrix.com> wrote:
> >>>>> On Fri, Jun 03, 2016 at 02:29:12AM -0600, Jan Beulich wrote:
> >>>>>> Ian, Wei,
> >>>>>>
> >>>>>> is it intentional that rebooting a (HVM) guest after having altered its
> >>>>>> vCPU count will reset it back to the vCPU count it was originally
> >>>>>> started with? That doesn't seem very natural - if one hotplugs a CPU
> >>>>>> into a physical system and then reboots, that CPU will remain there.
> >>>>>>
> >>>>> This is probably an oversight.
> >>>>>
> >>>>> I've added this to my list of things to look at after the release.
> >>>> Thanks!
> >>>>
> >>> I got a patch ready.  But QEMU upstream refuses to start on the receiving end
> >>> with following error message:
> >>>
> >>> qemu-system-i386: Unknown savevm section or instance 'cpu_common' 1
> >>> qemu-system-i386: load of migration failed: Invalid argument
> >>>
> >>> With QEMU traditional HVM guest and PV guest, the guest works fine -- up
> >>> and running with all hot plugged cpus available.
> >>>
> >>> So I think the relevant libxl information is transmitted but we also
> >>> need to fix QEMU upstream. But that's a separate issue.
> >>>
> >>> Wei.
> >>>
> >>> ---8<---
> >>> From 790ff77c6307b341dec0b4cc5e2d394e42f82e7c Mon Sep 17 00:00:00 2001
> >>> From: Wei Liu <wei.liu2@citrix.com>
> >>> Date: Fri, 3 Jun 2016 16:38:32 +0100
> >>> Subject: [PATCH] libxl: update vcpus bitmap in retrieved geust config
> >>>
> >>> ... because the available vcpu bitmap can change during domain life time
> >>> due to cpu hotplug and unplug.
> >>>
> >>> Reported-by: Jan Beulich <jbeulich@suse.com>
> >>> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> >> This patch has two issues:
> >> 1. The code to allocate bitmap is wrong
> >> 2. The check to see if vcpu is available is wrong
> >>
> >> It happens to work on PV and qemu-trad because they don't really rely
> >> on the bitmap provided.
> >>
> >> #1 is fixed.
> >>
> >> For #2, I haven't really gotten to the point today on how to correctly
> >> get the number of online vcpus.
> >>
> >> The current issue I discover is that:
> >>
> >>   xl vcpu-set jessie-hvm 4
> >>   xl list -l jessie-hvm | less # search for avail_vcpus
> >>
> >> A vcpu is not really considered online from xen's point of view, unless
> >> the guest explicitly activates it, like in guest `echo 1 >
> >> .../cpu1/online`.
> >>
> >> This is still not desirable because it would still cause qemu upstream
> >> migration to fail. I will see if there is other way to figure out how
> >> many vcpus are there.
> >>
> >> Off the top of my head I might need to interrogate QEMU for that. I will
> >> continue investigation later.
> >>
> >> Any hint on how to effectively identify online vcpus is very welcomed.
> 
> Why does qemu even care?  It has nothing to do with vcpu handling. 
> There should not be any qemu vcpu records in the first place.
> 

IIRC upstream rejected the idea of having no cpu attached to a platform.

Wei.

> ~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

  reply	other threads:[~2016-06-07  8:30 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-03  8:29 "xl vcpu-set" not persistent across reboot? Jan Beulich
2016-06-03 13:41 ` Wei Liu
2016-06-03 14:42   ` Jan Beulich
2016-06-03 16:35     ` Wei Liu
2016-06-06  8:58       ` Jan Beulich
2016-06-06 17:18       ` Wei Liu
2016-06-06 17:20         ` Wei Liu
2016-06-06 17:34           ` Andrew Cooper
2016-06-07  8:30             ` Wei Liu [this message]
2016-06-14 16:34               ` Ian Jackson
2016-06-14 16:39                 ` Wei Liu
2016-06-14 16:57                   ` Ian Jackson
2016-06-14 16:59                     ` Andrew Cooper
2016-06-14 17:06                       ` Wei Liu
2016-06-14 17:03                     ` Wei Liu
2016-06-14 17:23                       ` Wei Liu
2016-06-14 17:35                     ` Anthony PERARD
2016-06-07  6:38         ` Jan Beulich
2016-06-07  8:27           ` Wei Liu
  -- strict thread matches above, loose matches on Subject: below --
2016-06-06  9:04 Jan Beulich
2016-06-06 13:07 ` Stefano Stabellini
2016-06-06 13:42   ` Wei Liu
2016-06-06 14:00     ` Stefano Stabellini

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=20160607083021.GD25922@citrix.com \
    --to=wei.liu2@citrix.com \
    --cc=Ian.Jackson@eu.citrix.com \
    --cc=JBeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=anthony.perard@citrix.com \
    --cc=sstabellini@kernel.org \
    --cc=xen-devel@lists.xenproject.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).