All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <marc.zyngier@arm.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Auger Eric <eric.auger@redhat.com>,
	lkml - Kernel Mailing List <linux-kernel@vger.kernel.org>,
	arm-mail-list <linux-arm-kernel@lists.infradead.org>,
	kvmarm@lists.cs.columbia.edu
Subject: Re: [REPOST PATCH] arm/arm64: KVM: Add PSCI version selection API
Date: Tue, 06 Mar 2018 10:52:15 +0000	[thread overview]
Message-ID: <86woyp4gtc.wl-marc.zyngier@arm.com> (raw)
In-Reply-To: <CAFEAcA9-gVb-f25D4Ve9xvNUjuvd9iyL59MvNB9gqg8TK14JrA@mail.gmail.com>

On Tue, 06 Mar 2018 10:12:42 +0000,
peter maydell wrote:
> 
> On 6 March 2018 at 09:50, Marc Zyngier <marc.zyngier@arm.com> wrote:
> > On 05/03/18 20:37, Auger Eric wrote:
> >> On 05/03/18 17:31, Peter Maydell wrote:
> >>> That also means that we will fail migration from a new kernel where
> >>> we've specifically asked for PSCI 0.2 to an old PSCI-0.2-only kernel
> >>> (because the KVM_REG_ARM_PSCI_VERSION reg will appear in the migration
> >>> stream even if its value is the one value that matches the old kernel
> >>> behaviour). I don't know if we care about that.
> >>
> >> Do you know when are we likely to force PSCI 0.2 on a new kernel? At
> >> which layer is the decision supposed to be made and on which criteria?
> >
> > No decent SW should need this. But if you've written a guest that cannot
> > work if it doesn't get "2" as response to PSCI_VERSION, you can override it.
> 
> ...but if you want to be able to migrate back from a new kernel to
> an old one, then you need to ask the new kernel for 0.2 so it
> behaves the same way as the old one. As it stands this code wouldn't
> let you do that migration even if you did specifically ask for 0.2.
> (As I said, I don't know if we care about that.)

Absolutely. The moment we introduce a new sysreg, we create a
migration barrier. I'm not sure how the kernel can help in this
respect.

	M.

-- 
Jazz is not dead, it just smell funny.

WARNING: multiple messages have this Message-ID (diff)
From: marc.zyngier@arm.com (Marc Zyngier)
To: linux-arm-kernel@lists.infradead.org
Subject: [REPOST PATCH] arm/arm64: KVM: Add PSCI version selection API
Date: Tue, 06 Mar 2018 10:52:15 +0000	[thread overview]
Message-ID: <86woyp4gtc.wl-marc.zyngier@arm.com> (raw)
In-Reply-To: <CAFEAcA9-gVb-f25D4Ve9xvNUjuvd9iyL59MvNB9gqg8TK14JrA@mail.gmail.com>

On Tue, 06 Mar 2018 10:12:42 +0000,
peter maydell wrote:
> 
> On 6 March 2018 at 09:50, Marc Zyngier <marc.zyngier@arm.com> wrote:
> > On 05/03/18 20:37, Auger Eric wrote:
> >> On 05/03/18 17:31, Peter Maydell wrote:
> >>> That also means that we will fail migration from a new kernel where
> >>> we've specifically asked for PSCI 0.2 to an old PSCI-0.2-only kernel
> >>> (because the KVM_REG_ARM_PSCI_VERSION reg will appear in the migration
> >>> stream even if its value is the one value that matches the old kernel
> >>> behaviour). I don't know if we care about that.
> >>
> >> Do you know when are we likely to force PSCI 0.2 on a new kernel? At
> >> which layer is the decision supposed to be made and on which criteria?
> >
> > No decent SW should need this. But if you've written a guest that cannot
> > work if it doesn't get "2" as response to PSCI_VERSION, you can override it.
> 
> ...but if you want to be able to migrate back from a new kernel to
> an old one, then you need to ask the new kernel for 0.2 so it
> behaves the same way as the old one. As it stands this code wouldn't
> let you do that migration even if you did specifically ask for 0.2.
> (As I said, I don't know if we care about that.)

Absolutely. The moment we introduce a new sysreg, we create a
migration barrier. I'm not sure how the kernel can help in this
respect.

	M.

-- 
Jazz is not dead, it just smell funny.

  reply	other threads:[~2018-03-06 10:52 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-15 17:58 [REPOST PATCH] arm/arm64: KVM: Add PSCI version selection API Marc Zyngier
2018-02-15 17:58 ` Marc Zyngier
2018-03-02 10:44 ` Auger Eric
2018-03-02 10:44   ` Auger Eric
2018-03-02 11:11   ` Marc Zyngier
2018-03-02 11:11     ` Marc Zyngier
2018-03-02 11:11     ` Marc Zyngier
2018-03-02 12:26     ` Auger Eric
2018-03-02 12:26       ` Auger Eric
2018-03-05 16:31       ` Peter Maydell
2018-03-05 16:31         ` Peter Maydell
2018-03-05 20:37         ` Auger Eric
2018-03-05 20:37           ` Auger Eric
2018-03-06  9:50           ` Marc Zyngier
2018-03-06  9:50             ` Marc Zyngier
2018-03-06 10:12             ` Peter Maydell
2018-03-06 10:12               ` Peter Maydell
2018-03-06 10:52               ` Marc Zyngier [this message]
2018-03-06 10:52                 ` Marc Zyngier
2018-03-05 16:47     ` Peter Maydell
2018-03-05 16:47       ` Peter Maydell
2018-03-06  9:21       ` Andrew Jones
2018-03-06  9:21         ` Andrew Jones
2018-03-15 19:00         ` Marc Zyngier
2018-03-15 19:00           ` Marc Zyngier
2018-03-15 19:13           ` Peter Maydell
2018-03-15 19:13             ` Peter Maydell
2018-03-15 19:26             ` Marc Zyngier
2018-03-15 19:26               ` Marc Zyngier
2018-04-09 12:30               ` Christoffer Dall
2018-04-09 12:30                 ` Christoffer Dall
2018-04-09 12:47                 ` Marc Zyngier
2018-04-09 12:47                   ` Marc Zyngier
2018-04-09 13:05                   ` Christoffer Dall
2018-04-09 13:05                     ` Christoffer Dall
2018-04-09 13:20                     ` Marc Zyngier
2018-04-09 13:20                       ` Marc Zyngier

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=86woyp4gtc.wl-marc.zyngier@arm.com \
    --to=marc.zyngier@arm.com \
    --cc=eric.auger@redhat.com \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peter.maydell@linaro.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.