From: David Vrabel <david.vrabel@citrix.com>
To: Vitaly Kuznetsov <vkuznets@redhat.com>, <xen-devel@lists.xenproject.org>
Cc: Juergen Gross <jgross@suse.com>,
Stefano Stabellini <sstabellini@kernel.org>,
Andrew Cooper <andrew.cooper3@citrix.com>, <x86@kernel.org>,
<linux-kernel@vger.kernel.org>, Ingo Molnar <mingo@redhat.com>,
David Vrabel <david.vrabel@citrix.com>,
Jan Beulich <JBeulich@suse.com>, "H. Peter Anvin" <hpa@zytor.com>,
Boris Ostrovsky <boris.ostrovsky@oracle.com>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [Xen-devel] [PATCH linux v2 0/9] xen: pvhvm: support bootup on secondary vCPUs
Date: Mon, 25 Jul 2016 13:38:27 +0100 [thread overview]
Message-ID: <57960843.9070602@citrix.com> (raw)
In-Reply-To: <1467302203-22399-1-git-send-email-vkuznets@redhat.com>
On 30/06/16 16:56, Vitaly Kuznetsov wrote:
> It may happen that Xen's and Linux's ideas of vCPU id diverge. In
> particular, when we crash on a secondary vCPU we may want to do kdump
> and unlike plain kexec where we do migrate_to_reboot_cpu() we try booting
> on the vCPU which crashed. This doesn't work very well for PVHVM guests as
> we have a number of hypercalls where we pass vCPU id as a parameter. These
> hypercalls either fail or do something unexpected. To solve the issue we
> need to have a mapping between Linux's and Xen's vCPU ids.
>
> This series solves the issue for x86 PVHVM guests. PV guests don't (and
> probably won't) support kdump so I always assume Xen's vCPU id == Linux's
> vCPU id. ARM guests will probably need to get proper mapping once we start
> supporting kexec/kdump there.
Applied to for-linus-4.8, thanks.
David
next prev parent reply other threads:[~2016-07-25 12:38 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-30 15:56 [PATCH linux v2 0/9] xen: pvhvm: support bootup on secondary vCPUs Vitaly Kuznetsov
2016-06-30 15:56 ` [PATCH linux v2 1/9] x86/xen: update cpuid.h from Xen-4.7 Vitaly Kuznetsov
2016-06-30 15:56 ` Vitaly Kuznetsov
2016-06-30 15:56 ` [PATCH linux v2 2/9] x86/acpi: store ACPI ids from MADT for future usage Vitaly Kuznetsov
2016-06-30 15:56 ` Vitaly Kuznetsov
2016-06-30 15:56 ` [PATCH linux v2 3/9] xen: introduce xen_vcpu_id mapping Vitaly Kuznetsov
2016-06-30 15:56 ` Vitaly Kuznetsov
2016-06-30 15:56 ` [PATCH linux v2 4/9] x86/xen: use xen_vcpu_id mapping for HYPERVISOR_vcpu_op Vitaly Kuznetsov
2016-06-30 15:56 ` Vitaly Kuznetsov
2016-06-30 15:56 ` [PATCH linux v2 5/9] x86/xen: use xen_vcpu_id mapping when pointing vcpu_info to the shared_info page Vitaly Kuznetsov
2016-06-30 15:56 ` Vitaly Kuznetsov
2016-06-30 15:56 ` [PATCH linux v2 6/9] xen/events: use xen_vcpu_id mapping in events_base Vitaly Kuznetsov
2016-06-30 15:56 ` Vitaly Kuznetsov
2016-06-30 15:56 ` [PATCH linux v2 7/9] xen/events: fifo: use xen_vcpu_id mapping Vitaly Kuznetsov
2016-06-30 15:56 ` Vitaly Kuznetsov
2016-06-30 15:56 ` [PATCH linux v2 8/9] xen/evtchn: " Vitaly Kuznetsov
2016-06-30 15:56 ` Vitaly Kuznetsov
2016-06-30 15:56 ` [PATCH linux v2 9/9] xen/pvhvm: run xen_vcpu_setup() for the boot CPU Vitaly Kuznetsov
2016-06-30 15:56 ` Vitaly Kuznetsov
2016-07-25 9:17 ` [PATCH linux v2 0/9] xen: pvhvm: support bootup on secondary vCPUs Vitaly Kuznetsov
2016-07-25 9:17 ` Vitaly Kuznetsov
2016-07-25 12:38 ` David Vrabel [this message]
2016-07-25 13:17 ` Julien Grall
2016-07-25 13:17 ` [Xen-devel] " Julien Grall
2016-07-25 13:39 ` Vitaly Kuznetsov
2016-07-25 13:39 ` [Xen-devel] " Vitaly Kuznetsov
2016-07-25 14:01 ` Julien Grall
2016-07-25 14:09 ` David Vrabel
2016-07-25 14:09 ` [Xen-devel] " David Vrabel
2016-07-25 14:19 ` Vitaly Kuznetsov
2016-07-25 19:18 ` Stefano Stabellini
2016-07-26 8:28 ` Vitaly Kuznetsov
2016-07-26 8:28 ` Vitaly Kuznetsov
2016-07-25 19:18 ` Stefano Stabellini
2016-07-25 14:19 ` Vitaly Kuznetsov
2016-07-25 21:37 ` [Xen-devel] " Stefano Stabellini
2016-07-25 21:37 ` Stefano Stabellini
2016-07-25 14:01 ` Julien Grall
2016-07-25 13:43 ` [Xen-devel] " David Vrabel
2016-07-25 21:16 ` Stefano Stabellini
2016-07-25 21:16 ` Stefano Stabellini
2016-07-25 13:43 ` David Vrabel
2016-07-25 12:38 ` David Vrabel
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=57960843.9070602@citrix.com \
--to=david.vrabel@citrix.com \
--cc=JBeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=boris.ostrovsky@oracle.com \
--cc=hpa@zytor.com \
--cc=jgross@suse.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=sstabellini@kernel.org \
--cc=tglx@linutronix.de \
--cc=vkuznets@redhat.com \
--cc=x86@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.