From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1755394AbcGZNTw (ORCPT <rfc822;w@1wt.eu>);
	Tue, 26 Jul 2016 09:19:52 -0400
Received: from mx1.redhat.com ([209.132.183.28]:44406 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1754687AbcGZNTv (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 26 Jul 2016 09:19:51 -0400
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: David Vrabel <david.vrabel@citrix.com>
Cc: <xen-devel@lists.xenproject.org>, Juergen Gross <jgross@suse.com>,
        Stefano Stabellini <sstabellini@kernel.org>,
        Andrew Cooper <andrew.cooper3@citrix.com>, <x86@kernel.org>,
        <linux-kernel@vger.kernel.org>, Julien Grall <julien.grall@arm.com>,
        Ingo Molnar <mingo@redhat.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 v3 0/9] xen: pvhvm: support bootup on secondary vCPUs
References: <1469536228-29932-1-git-send-email-vkuznets@redhat.com>
	<57975F83.9090604@citrix.com>
Date: Tue, 26 Jul 2016 15:19:46 +0200
In-Reply-To: <57975F83.9090604@citrix.com> (David Vrabel's message of "Tue, 26
	Jul 2016 14:02:59 +0100")
Message-ID: <87lh0ov8nh.fsf@vitty.brq.redhat.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.95 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Tue, 26 Jul 2016 13:19:50 +0000 (UTC)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

David Vrabel <david.vrabel@citrix.com> writes:

> On 26/07/16 13:30, 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.
>> 
>> Changes since v2:
>> - Use 'uint32_t' for xen_vcpu_id mapping [Julien Grall]
>> - Rebased to linux-4.7
>
> I already applied v2.  If you provide an incremental patch I can queue
> it for 4.9.

Ok,

in that case we can wait till the real mapping is done for ARM to change
the type of xen_vcpu_id I guess.

-- 
  Vitaly