From: konrad@kernel.org
To: xen-devel@lists.xenproject.org, david.vrabel@Citrix.com,
boris.ostrovsky@oracle.com, linux-kernel@vger.kernel.org,
keir@xen.org, jbeulich@suse.com
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [XEN PATCH 1/2] hvm: Support more than 32 VCPUS when migrating.
Date: Tue, 8 Apr 2014 13:25:49 -0400 [thread overview]
Message-ID: <1396977950-8789-2-git-send-email-konrad@kernel.org> (raw)
In-Reply-To: <1396977950-8789-1-git-send-email-konrad@kernel.org>
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
When we migrate an HVM guest, by default our shared_info can
only hold up to 32 CPUs. As such the hypercall
VCPUOP_register_vcpu_info was introduced which allowed us to
setup per-page areas for VCPUs. This means we can boot PVHVM
guest with more than 32 VCPUs. During migration the per-cpu
structure is allocated fresh by the hypervisor (vcpu_info_mfn
is set to INVALID_MFN) so that the newly migrated guest
can do make the VCPUOP_register_vcpu_info hypercall.
Unfortunatly we end up triggering this condition:
/* Run this command on yourself or on other offline VCPUS. */
if ( (v != current) && !test_bit(_VPF_down, &v->pause_flags) )
which means we are unable to setup the per-cpu VCPU structures
for running vCPUS. The Linux PV code paths make this work by
iterating over every vCPU with:
1) is target CPU up (VCPUOP_is_up hypercall?)
2) if yes, then VCPUOP_down to pause it.
3) VCPUOP_register_vcpu_info
4) if it was down, then VCPUOP_up to bring it back up
But since VCPUOP_down, VCPUOP_is_up, and VCPUOP_up are
not allowed on HVM guests we can't do this. This patch
enables this.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
xen/arch/x86/hvm/hvm.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 38c491e..b5b92fe 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3470,6 +3470,9 @@ static long hvm_vcpu_op(
case VCPUOP_stop_singleshot_timer:
case VCPUOP_register_vcpu_info:
case VCPUOP_register_vcpu_time_memory_area:
+ case VCPUOP_down:
+ case VCPUOP_up:
+ case VCPUOP_is_up:
rc = do_vcpu_op(cmd, vcpuid, arg);
break;
default:
--
1.7.7.6
next prev parent reply other threads:[~2014-04-08 17:24 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-04 20:44 33 VCPUs in HVM guests with live migration with Linux hangs Konrad Rzeszutek Wilk
2014-04-07 8:32 ` Ian Campbell
2014-04-08 17:25 ` [PATCH] Fixes for more than 32 VCPUs migration for HVM guests (v1) konrad
2014-04-08 17:25 ` [XEN PATCH 1/2] hvm: Support more than 32 VCPUS when migrating konrad
2014-04-08 17:25 ` konrad [this message]
2014-04-08 18:18 ` Roger Pau Monné
2014-04-08 18:18 ` [Xen-devel] " Roger Pau Monné
2014-04-08 18:53 ` Konrad Rzeszutek Wilk
2014-04-09 7:37 ` Roger Pau Monné
2014-04-09 15:34 ` Konrad Rzeszutek Wilk
2014-04-09 15:34 ` [Xen-devel] " Konrad Rzeszutek Wilk
2014-04-09 15:38 ` David Vrabel
2014-04-09 15:55 ` Konrad Rzeszutek Wilk
2014-04-09 15:55 ` [Xen-devel] " Konrad Rzeszutek Wilk
2014-04-09 15:38 ` David Vrabel
2014-04-09 7:37 ` Roger Pau Monné
2014-04-09 8:33 ` [Xen-devel] " Ian Campbell
2014-04-09 9:04 ` Roger Pau Monné
2014-04-09 9:04 ` Roger Pau Monné
2014-04-09 8:33 ` Ian Campbell
2014-04-08 18:53 ` Konrad Rzeszutek Wilk
2014-04-09 9:06 ` Jan Beulich
2014-04-09 15:27 ` Konrad Rzeszutek Wilk
2014-04-09 15:27 ` Konrad Rzeszutek Wilk
2014-04-09 15:36 ` Jan Beulich
2014-04-22 18:34 ` Konrad Rzeszutek Wilk
2014-04-23 8:57 ` Jan Beulich
2014-04-23 8:57 ` Jan Beulich
2014-04-22 18:34 ` Konrad Rzeszutek Wilk
2014-04-09 15:36 ` Jan Beulich
2014-04-09 9:06 ` Jan Beulich
2014-04-08 17:25 ` [LINUX PATCH 2/2] xen/pvhvm: Support more than 32 VCPUs " konrad
2014-04-09 8:03 ` Jan Beulich
2014-04-09 8:03 ` Jan Beulich
2014-04-08 17:25 ` konrad
2014-04-08 17:25 ` [PATCH] Fixes for more than 32 VCPUs migration for HVM guests (v1) konrad
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=1396977950-8789-2-git-send-email-konrad@kernel.org \
--to=konrad@kernel.org \
--cc=boris.ostrovsky@oracle.com \
--cc=david.vrabel@Citrix.com \
--cc=jbeulich@suse.com \
--cc=keir@xen.org \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.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 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.