From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.3 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_2 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A651AC433DB for ; Mon, 4 Jan 2021 12:47:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 69AD7221E5 for ; Mon, 4 Jan 2021 12:47:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726240AbhADMrr (ORCPT ); Mon, 4 Jan 2021 07:47:47 -0500 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:1478 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725889AbhADMrq (ORCPT ); Mon, 4 Jan 2021 07:47:46 -0500 Received: from pps.filterd (m0098394.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 104CVrRO131846; Mon, 4 Jan 2021 07:46:39 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=date : from : to : cc : subject : message-id : in-reply-to : references : mime-version : content-type : content-transfer-encoding; s=pp1; bh=ewbAY50v/8FSpvqbM398JgtgepRI2tpoNwMV7GL3pvY=; b=DTF+ZyCvDdR6uM1LM8twZ7mlboBptES+dArJQjRpvTLroBHmtKBVZZan4rPgYuDAG4vT RhxZf1Z/JLanlJnDSZ87EWUcupm8e2PGTBd0TeJ/WfO9PZLz/ynJd959aD0ZTy3aJjzj /oy1OQXUjrpo8gNiphKxU6MoNy9UkiVpvgBbKciqS7aPKonmwD2t528fZWnY7gwuBkEI sv7Pqc5l5v+mLyJkNHc23fY6XzbnwsVifyVvvZ7Hgdxb3TpVWgVBV0zLvtBx72ERN78v aOaeY3OSHfnYowTnfoa3T1pUaTQCu3IHsEvFnXeU8QH0AVlJcfEdzK2weVXHQp4AOnaB Ew== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 35v2cp9ga6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 04 Jan 2021 07:46:39 -0500 Received: from m0098394.ppops.net (m0098394.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.36/8.16.0.36) with SMTP id 104CW9dc136633; Mon, 4 Jan 2021 07:46:38 -0500 Received: from ppma06ams.nl.ibm.com (66.31.33a9.ip4.static.sl-reverse.com [169.51.49.102]) by mx0a-001b2d01.pphosted.com with ESMTP id 35v2cp9g98-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 04 Jan 2021 07:46:38 -0500 Received: from pps.filterd (ppma06ams.nl.ibm.com [127.0.0.1]) by ppma06ams.nl.ibm.com (8.16.0.42/8.16.0.42) with SMTP id 104CVSIM013181; Mon, 4 Jan 2021 12:46:36 GMT Received: from b06cxnps3074.portsmouth.uk.ibm.com (d06relay09.portsmouth.uk.ibm.com [9.149.109.194]) by ppma06ams.nl.ibm.com with ESMTP id 35tg3h9vr6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 04 Jan 2021 12:46:35 +0000 Received: from d06av25.portsmouth.uk.ibm.com (d06av25.portsmouth.uk.ibm.com [9.149.105.61]) by b06cxnps3074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 104CkXJB33489154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 4 Jan 2021 12:46:33 GMT Received: from d06av25.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id EDABA11C052; Mon, 4 Jan 2021 12:46:32 +0000 (GMT) Received: from d06av25.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E5E6B11C04C; Mon, 4 Jan 2021 12:46:31 +0000 (GMT) Received: from li-e979b1cc-23ba-11b2-a85c-dfd230f6cf82 (unknown [9.171.76.119]) by d06av25.portsmouth.uk.ibm.com (Postfix) with SMTP; Mon, 4 Jan 2021 12:46:31 +0000 (GMT) Date: Mon, 4 Jan 2021 13:46:29 +0100 From: Halil Pasic To: Ram Pai Cc: Cornelia Huck , Greg Kurz , pair@us.ibm.com, brijesh.singh@amd.com, kvm@vger.kernel.org, "Michael S. Tsirkin" , qemu-devel@nongnu.org, frankja@linux.ibm.com, david@redhat.com, mdroth@linux.vnet.ibm.com, borntraeger@de.ibm.com, David Gibson , thuth@redhat.com, Eduardo Habkost , Richard Henderson , dgilbert@redhat.com, qemu-s390x@nongnu.org, rth@twiddle.net, berrange@redhat.com, Marcelo Tosatti , qemu-ppc@nongnu.org, pbonzini@redhat.com Subject: Re: [EXTERNAL] Re: [for-6.0 v5 11/13] spapr: PEF: prevent migration Message-ID: <20210104134629.49997b53.pasic@linux.ibm.com> In-Reply-To: <20210104071550.GA22585@ram-ibm-com.ibm.com> References: <20201204054415.579042-1-david@gibson.dropbear.id.au> <20201204054415.579042-12-david@gibson.dropbear.id.au> <20201214182240.2abd85eb.cohuck@redhat.com> <20201217054736.GH310465@yekko.fritz.box> <20201217123842.51063918.cohuck@redhat.com> <20201217151530.54431f0e@bahia.lan> <20201218124111.4957eb50.cohuck@redhat.com> <20210104071550.GA22585@ram-ibm-com.ibm.com> Organization: IBM X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343,18.0.737 definitions=2021-01-04_07:2021-01-04,2021-01-04 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxlogscore=999 spamscore=0 malwarescore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 bulkscore=0 mlxscore=0 suspectscore=0 priorityscore=1501 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2101040081 Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Sun, 3 Jan 2021 23:15:50 -0800 Ram Pai wrote: > On Fri, Dec 18, 2020 at 12:41:11PM +0100, Cornelia Huck wrote: > > On Thu, 17 Dec 2020 15:15:30 +0100 [..] > > > > > > > +int kvmppc_svm_init(SecurableGuestMemory *sgm, Error **errp) > > > > > > > { > > > > > > > if (!kvm_check_extension(kvm_state, KVM_CAP_PPC_SECURABLE_GUEST)) { > > > > > > > error_setg(errp, > > > > > > > @@ -54,6 +58,11 @@ static int kvmppc_svm_init(Error **errp) > > > > > > > } > > > > > > > } > > > > > > > > > > > > > > + /* add migration blocker */ > > > > > > > + error_setg(&pef_mig_blocker, "PEF: Migration is not implemented"); > > > > > > > + /* NB: This can fail if --only-migratable is used */ > > > > > > > + migrate_add_blocker(pef_mig_blocker, &error_fatal); > > > > > > > > > > > > Just so that I understand: is PEF something that is enabled by the host > > > > > > (and the guest is either secured or doesn't start), or is it using a > > > > > > model like s390x PV where the guest initiates the transition into > > > > > > secured mode? > > > > > > > > > > Like s390x PV it's initiated by the guest. > > > > > > > > > > > Asking because s390x adds the migration blocker only when the > > > > > > transition is actually happening (i.e. guests that do not transition > > > > > > into secure mode remain migratable.) This has the side effect that you > > > > > > might be able to start a machine with --only-migratable that > > > > > > transitions into a non-migratable machine via a guest action, if I'm > > > > > > not mistaken. Without the new object, I don't see a way to block with > > > > > > --only-migratable; with it, we should be able to do that. Not sure what > > > > > > the desirable behaviour is here. > > > > > > > > > > > The purpose of --only-migratable is specifically to prevent the machine > > > to transition to a non-migrate state IIUC. The guest transition to > > > secure mode should be nacked in this case. > > > > Yes, that's what happens for s390x: The guest tries to transition, QEMU > > can't add a migration blocker and fails the instruction used for > > transitioning, the guest sees the error. > > > > The drawback is that we see the failure only when we already launched > > the machine and the guest tries to transition. If I start QEMU with > > --only-migratable, it will refuse to start when non-migratable devices > > are configured in the command line, so I see the issue right from the > > start. (For s390x, that would possibly mean that we should not even > > present the cpu feature bit when only_migratable is set?) > > What happens in s390x, if the guest tries to transition to secure, when > the secure object is NOT configured on the machine? > Nothing in particular. > On PEF systems, the transition fails and the guest is terminated. > > My point is -- QEMU will not be able to predict in advance, what the > guest might or might not do, regardless of what devices and objects are > configured in the machine. If the guest does something unexpected, it > has to be terminated. We can't fail transition to secure when the secure object is not configured on the machine, because that would break pre-existing setups. This feature is still to be shipped, but secure execution has already been shipped, but without migration support. That's why when you have both the secure object configured, and mandate migratability, the we can fail. Actually we should fail now, because the two options are not compatible: you can't have a qemu that is guaranteed to be migratable, and guaranteed to be able to operate in secure execution mode today. Failing early, and not on the guests opt-in would be preferable. After migration support is added, the combo should be fine, and probably also the default for secure execution machines. > > So one possible design choice is to let the guest know that migration > must be facilitated. It can then decide if it wants to continue as a > normal VM or terminate itself, or take the plunge and switch to secure. > A well behaving guest will not switch to secure. > I don't understand this point. Sorry. Regards, Halil [..]