All of lore.kernel.org
 help / color / mirror / Atom feed
From: Auger Eric <eric.auger@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Marc Zyngier <marc.zyngier@arm.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: Mon, 5 Mar 2018 21:37:08 +0100	[thread overview]
Message-ID: <a1579f14-a5fe-11bc-a831-f729cead25ba@redhat.com> (raw)
In-Reply-To: <CAFEAcA9=YpNngKqeOXiO7QDvL=1ZaQEW8fh3XHjwD+i8qQm9wg@mail.gmail.com>

Hi Peter,

On 05/03/18 17:31, Peter Maydell wrote:
> On 2 March 2018 at 12:26, Auger Eric <eric.auger@redhat.com> wrote:
>> Hi Marc,
>> On 02/03/18 12:11, Marc Zyngier wrote:
>>> On Fri, 02 Mar 2018 10:44:48 +0000,
>>> Auger Eric wrote:
>>>> I understand the get/set is called as part of the migration process.
>>>> So my understanding is the benefit of this series is migration fails in
>>>> those cases:
>>>>
>>>>> =0.2 source -> 0.1 destination
>>>> 0.1 source -> >=0.2 destination
>>>
>>> It also fails in the case where you migrate a 1.0 guest to something
>>> that cannot support it.
>>
>> That's because on the destination, the number of regs is less than on
>> source, right?
> 
> I think it fails because the KVM_REG_ARM_PSCI_VERSION register will be
> in the migration state but not in the destination's list of registers:
> the code in QEMU's target/arm/machine.c:cpu_post_load() function that
> checks "register in their list but not ours: fail migration" will
> catch this.

Thank you for the pointer. Yes at the time I reviewed the patch and just
focusing on the kernel code, this was not immediate to me.

> 
> 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?

Thanks

Eric
> 
> thanks
> -- PMM
> 

WARNING: multiple messages have this Message-ID (diff)
From: eric.auger@redhat.com (Auger Eric)
To: linux-arm-kernel@lists.infradead.org
Subject: [REPOST PATCH] arm/arm64: KVM: Add PSCI version selection API
Date: Mon, 5 Mar 2018 21:37:08 +0100	[thread overview]
Message-ID: <a1579f14-a5fe-11bc-a831-f729cead25ba@redhat.com> (raw)
In-Reply-To: <CAFEAcA9=YpNngKqeOXiO7QDvL=1ZaQEW8fh3XHjwD+i8qQm9wg@mail.gmail.com>

Hi Peter,

On 05/03/18 17:31, Peter Maydell wrote:
> On 2 March 2018 at 12:26, Auger Eric <eric.auger@redhat.com> wrote:
>> Hi Marc,
>> On 02/03/18 12:11, Marc Zyngier wrote:
>>> On Fri, 02 Mar 2018 10:44:48 +0000,
>>> Auger Eric wrote:
>>>> I understand the get/set is called as part of the migration process.
>>>> So my understanding is the benefit of this series is migration fails in
>>>> those cases:
>>>>
>>>>> =0.2 source -> 0.1 destination
>>>> 0.1 source -> >=0.2 destination
>>>
>>> It also fails in the case where you migrate a 1.0 guest to something
>>> that cannot support it.
>>
>> That's because on the destination, the number of regs is less than on
>> source, right?
> 
> I think it fails because the KVM_REG_ARM_PSCI_VERSION register will be
> in the migration state but not in the destination's list of registers:
> the code in QEMU's target/arm/machine.c:cpu_post_load() function that
> checks "register in their list but not ours: fail migration" will
> catch this.

Thank you for the pointer. Yes at the time I reviewed the patch and just
focusing on the kernel code, this was not immediate to me.

> 
> 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?

Thanks

Eric
> 
> thanks
> -- PMM
> 

  reply	other threads:[~2018-03-05 20:37 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 [this message]
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
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=a1579f14-a5fe-11bc-a831-f729cead25ba@redhat.com \
    --to=eric.auger@redhat.com \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marc.zyngier@arm.com \
    --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.