Received: by 10.223.185.116 with SMTP id b49csp3587127wrg; Tue, 6 Mar 2018 01:22:47 -0800 (PST) X-Google-Smtp-Source: AG47ELv/rD3ChSs7x1tgoZOp/QjIy0NDqjgNiNgycwup4jcbcsB5SUxHWjZ5iuxn7fWe3gyepLiy X-Received: by 2002:a17:902:5489:: with SMTP id e9-v6mr14109398pli.81.1520328167885; Tue, 06 Mar 2018 01:22:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520328167; cv=none; d=google.com; s=arc-20160816; b=O4kT7dGiXVj8ycKM+OH2OcfFP+fOZVp4DLYHFXiRBZuujk0zzqJUWsk79a8HwECOrL +xaScU5UwZTFcwPzEy+AI05Rv5jPgbQZEacT3NbB1NQ3PddIz8ywWMLJizcwEkX2lfN0 vqxDgbbjtq0Ll5STmNHOlUU9TvpzyDGT9DlG1qpbPET1O1olir4WSu5BggL8EIrs6QyB NN+JZ6CBzawcQTVlEJ2kjbpukUgVu7ISr1tOUbfg4koMh2rW5m5opY09/e+h5RaxS7k0 bMjIDAjEd4Z8h6IBNFMfryn6kG+1OJ37eIEJ0KiWRC2IJ+0bmmnnXu9aWyW3NCpn01Kl zhDA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=ZgoEmImkxaBzIJKkDDNHHtTPTiy0VdHO3eMIAjEW+cg=; b=cKpPDt8i2VONkIIgeEetnLiI+8yE/LxY7/Q5XmUUYzqE2gccvT3HYJd4mPMOa3a4Tl NkuITUZN/u1x7vk++l5nde/cVaIJHsrq6Bm5+O9tyf1blaGGz4IWdbNhohnTjq28xx8J nAhVhiD7bLWnAwqKX0EdPAURWBrxykyfuvvmox/geV7A/9TsSWgYI9dwT0YDTBpw1VAo k7lLW8rZF6kkgGpjAUztaMWkE9lCCwiSvAjnDZHoOhqqsD4hBEbHobQYpfvI8uTQxSx1 3D5NuaZweRdkPRwcpSK6lyIc67+iZRR/Ye0eQV/y/W1WGRiKd6t+U6ManICNvYUGPYU/ Vlnw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n11-v6si10652726plg.134.2018.03.06.01.22.32; Tue, 06 Mar 2018 01:22:47 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752905AbeCFJVl (ORCPT + 99 others); Tue, 6 Mar 2018 04:21:41 -0500 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:42276 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750836AbeCFJVi (ORCPT ); Tue, 6 Mar 2018 04:21:38 -0500 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 104648185322; Tue, 6 Mar 2018 09:21:38 +0000 (UTC) Received: from kamzik.brq.redhat.com (unknown [10.43.2.160]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E7358111E3E6; Tue, 6 Mar 2018 09:21:36 +0000 (UTC) Date: Tue, 6 Mar 2018 10:21:34 +0100 From: Andrew Jones To: Peter Maydell Cc: Marc Zyngier , lkml - Kernel Mailing List , arm-mail-list , kvmarm@lists.cs.columbia.edu Subject: Re: [REPOST PATCH] arm/arm64: KVM: Add PSCI version selection API Message-ID: <20180306092134.4bfbz34yhqfrfdlf@kamzik.brq.redhat.com> References: <20180215175803.6870-1-marc.zyngier@arm.com> <86o9k63f7a.wl-marc.zyngier@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0.1 (2016-04-01) X-Scanned-By: MIMEDefang 2.78 on 10.11.54.3 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.8]); Tue, 06 Mar 2018 09:21:38 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.8]); Tue, 06 Mar 2018 09:21:38 +0000 (UTC) for IP:'10.11.54.3' DOMAIN:'int-mx03.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'drjones@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 05, 2018 at 04:47:55PM +0000, Peter Maydell wrote: > On 2 March 2018 at 11: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. > > I think it would be useful if we could write out the various > combinations of source, destination and what we expect/want to > have happen. My gut feeling here is that we're sacrificing > exact migration compatibility in favour of having the guest > automatically get the variant-2 mitigations, but it's not clear > to me exactly which migration combinations that's intended to > happen for. Marc? > > If this wasn't a mitigation issue the desired behaviour would be > straightforward: > * kernel should default to 0.2 on the basis that > that's what it did before > * new QEMU version should enable 1.0 by default for virt-2.12 > and 0.2 for virt-2.11 and earlier > * PSCI version info shouldn't appear in migration stream unless > it's something other than 0.2 > But that would leave some setups (which?) unnecessarily without the > mitigation, so we're not doing that. The question is, exactly > what *are* we aiming for? The reason Marc dropped this patch from the series it was first introduced in was because we didn't have the aim 100% understood. We want the mitigation by default, but also to have the least chance of migration failure, and when we must fail (because we're not doing the straightforward approach listed above, which would prevent failures), then we want to fail with the least amount of damage to the user. I experimented with a couple different approaches and provided tables[1] with my results. I even recommended an approach, but I may have changed my mind after reading Marc's follow-up[2]. The thread continues from there as well with follow-ups from Christoffer, Marc, and myself. Anyway, Marc did this repost for us to debate it and work out the best approach here. Thanks, drew [1] https://www.spinics.net/lists/arm-kernel/msg632355.html [2] https://www.spinics.net/lists/arm-kernel/msg632385.html