[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.10.1607251407270.12319@sstabellini-ThinkPad-X260>
Date: Mon, 25 Jul 2016 14:16:26 -0700 (PDT)
From: Stefano Stabellini <sstabellini@...nel.org>
To: David Vrabel <david.vrabel@...rix.com>
cc: Julien Grall <julien.grall@....com>,
Vitaly Kuznetsov <vkuznets@...hat.com>,
xen-devel@...ts.xenproject.org, Juergen Gross <jgross@...e.com>,
Stefano Stabellini <sstabellini@...nel.org>,
Andrew Cooper <andrew.cooper3@...rix.com>, x86@...nel.org,
linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...hat.com>,
Jan Beulich <JBeulich@...e.com>,
"H. Peter Anvin" <hpa@...or.com>,
Boris Ostrovsky <boris.ostrovsky@...cle.com>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [Xen-devel] [PATCH linux v2 0/9] xen: pvhvm: support bootup on
secondary vCPUs
On Mon, 25 Jul 2016, David Vrabel wrote:
> On 25/07/16 14:17, Julien Grall wrote:
> > Hi David,
> >
> > On 25/07/16 13:38, David Vrabel wrote:
> >> 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.
> >
> > It would have been nice to send a ping before applying. This patch
> > series is containing Xen ARM code which has not been acked by Stefano,
> > nor had feedback from ARM side.
>
> The ARM parts are trivial and such a small part of this series, I saw no
> need to wait.
That's OK, no worries. In the future it would be nice to wait a few more
hours, until morning PST.
Cheers,
Stefano
Powered by blists - more mailing lists