[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <871t3gwe0o.fsf@vitty.brq.redhat.com>
Date: Wed, 29 Jun 2016 11:16:55 +0200
From: Vitaly Kuznetsov <vkuznets@...hat.com>
To: David Vrabel <david.vrabel@...rix.com>
Cc: <xen-devel@...ts.xenproject.org>, <linux-kernel@...r.kernel.org>,
<x86@...nel.org>, Stefano Stabellini <sstabellini@...nel.org>,
Boris Ostrovsky <boris.ostrovsky@...cle.com>,
Juergen Gross <jgross@...e.com>,
Thomas Gleixner <tglx@...utronix.de>,
"Ingo Molnar" <mingo@...hat.com>, "H. Peter Anvin" <hpa@...or.com>,
Julien Grall <julien.grall@...rix.com>
Subject: Re: [PATCH linux 0/8] xen: pvhvm: support bootup on secondary vCPUs
David Vrabel <david.vrabel@...rix.com> writes:
> On 28/06/16 17:47, 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.
>
> Could the soft-reboot hypercall (optionally) return on vcpu 0?
>
In theory, yes, I think we can re-arrange vCPUs inside the hypervisor so
Linux will get them in the natural order after soft reset.
--
Vitaly
Powered by blists - more mailing lists