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=-15.1 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable 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 9CE84C433E0 for ; Mon, 4 Jan 2021 07:19:52 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id DBBA7206F4 for ; Mon, 4 Jan 2021 07:19:51 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DBBA7206F4 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=us.ibm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:36284 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kwK9e-0006aU-IQ for qemu-devel@archiver.kernel.org; Mon, 04 Jan 2021 02:19:50 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:38472) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kwK6U-0005HF-ET; Mon, 04 Jan 2021 02:16:36 -0500 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:65126) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kwK6J-0003Pe-GD; Mon, 04 Jan 2021 02:16:32 -0500 Received: from pps.filterd (m0098417.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 10473EwP011904; Mon, 4 Jan 2021 02:16:04 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=date : from : to : cc : message-id : reply-to : references : mime-version : content-type : in-reply-to : subject; s=pp1; bh=UPh3XwP1kEMkh2iasn5Ypwtn/eLjqUiyXcFMlS70N3c=; b=BcSWJXD+9OOxcrLXXfBOGVp74TrlDBtqF+u5KkGPmJBzks4+GXV66PAEUFYHc0r2Pj0X 1bxMOHpwpecMeGTLYtJt7KVyRueL3cbn3rFmdJDf6U/etLHyk6LqlsCwCEJ0iVfmoF7S teuxn6KR8oEE/8/cQEDVHxT4yoW15tBLETXeiYw49V8vlR+CveuT+MCxM3uDkYXHHr6+ 7kvy2EWO5/MxKTiwS0WV/hs8I2yD4Mf7txuL9eM8tMTzYpaHRby2xyp/207Z0QNBLeFz wmDHgxkwcUSSPNaX7IkyTfhuzixdEjtggy2rDL3PObtbP5QPdPw9MGcZcPfC7oaj8YST Rw== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 35uva8jphb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 04 Jan 2021 02:16:03 -0500 Received: from m0098417.ppops.net (m0098417.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.36/8.16.0.36) with SMTP id 10473wDK014152; Mon, 4 Jan 2021 02:16:03 -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 35uva8jpgu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 04 Jan 2021 02:16:03 -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 1047Dnap002886; Mon, 4 Jan 2021 07:16:01 GMT Received: from b06avi18878370.portsmouth.uk.ibm.com (b06avi18878370.portsmouth.uk.ibm.com [9.149.26.194]) by ppma06ams.nl.ibm.com with ESMTP id 35tg3h9m4k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 04 Jan 2021 07:16:01 +0000 Received: from d06av23.portsmouth.uk.ibm.com (d06av23.portsmouth.uk.ibm.com [9.149.105.59]) by b06avi18878370.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 1047Ftfd24772880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 4 Jan 2021 07:15:55 GMT Received: from d06av23.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 39AFFA4057; Mon, 4 Jan 2021 07:15:58 +0000 (GMT) Received: from d06av23.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id BA254A4055; Mon, 4 Jan 2021 07:15:53 +0000 (GMT) Received: from ram-ibm-com.ibm.com (unknown [9.163.29.145]) by d06av23.portsmouth.uk.ibm.com (Postfix) with ESMTPS; Mon, 4 Jan 2021 07:15:53 +0000 (GMT) Date: Sun, 3 Jan 2021 23:15:50 -0800 From: Ram Pai To: Cornelia Huck Message-ID: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201218124111.4957eb50.cohuck@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 Subject: Re: Re: [for-6.0 v5 11/13] spapr: PEF: prevent migration X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2021-01-04_04:2020-12-31, 2021-01-04 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1011 impostorscore=0 lowpriorityscore=0 malwarescore=0 suspectscore=0 bulkscore=0 mlxscore=0 mlxlogscore=999 spamscore=0 priorityscore=1501 phishscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2101040047 Received-SPF: pass client-ip=148.163.158.5; envelope-from=linuxram@us.ibm.com; helo=mx0b-001b2d01.pphosted.com X-Spam_score_int: -26 X-Spam_score: -2.7 X-Spam_bar: -- X-Spam_report: (-2.7 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Ram Pai Cc: 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, pasic@linux.ibm.com, borntraeger@de.ibm.com, David Gibson , thuth@redhat.com, Eduardo Habkost , Richard Henderson , Greg Kurz , dgilbert@redhat.com, qemu-s390x@nongnu.org, rth@twiddle.net, berrange@redhat.com, Marcelo Tosatti , qemu-ppc@nongnu.org, pbonzini@redhat.com Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Fri, Dec 18, 2020 at 12:41:11PM +0100, Cornelia Huck wrote: > On Thu, 17 Dec 2020 15:15:30 +0100 > Greg Kurz wrote: > > > On Thu, 17 Dec 2020 12:38:42 +0100 > > Cornelia Huck wrote: > > > > > On Thu, 17 Dec 2020 16:47:36 +1100 > > > David Gibson wrote: > > > > > > > On Mon, Dec 14, 2020 at 06:22:40PM +0100, Cornelia Huck wrote: > > > > > On Fri, 4 Dec 2020 16:44:13 +1100 > > > > > David Gibson wrote: > > > > > > > > > > > We haven't yet implemented the fairly involved handshaking that will be > > > > > > needed to migrate PEF protected guests. For now, just use a migration > > > > > > blocker so we get a meaningful error if someone attempts this (this is the > > > > > > same approach used by AMD SEV). > > > > > > > > > > > > Signed-off-by: David Gibson > > > > > > Reviewed-by: Dr. David Alan Gilbert > > > > > > --- > > > > > > hw/ppc/pef.c | 9 +++++++++ > > > > > > 1 file changed, 9 insertions(+) > > > > > > > > > > > > diff --git a/hw/ppc/pef.c b/hw/ppc/pef.c > > > > > > index 3ae3059cfe..edc3e744ba 100644 > > > > > > --- a/hw/ppc/pef.c > > > > > > +++ b/hw/ppc/pef.c > > > > > > @@ -38,7 +38,11 @@ struct PefGuestState { > > > > > > }; > > > > > > > > > > > > #ifdef CONFIG_KVM > > > > > > +static Error *pef_mig_blocker; > > > > > > + > > > > > > static int kvmppc_svm_init(Error **errp) > > > > > > > > > > This looks weird? > > > > > > > > Oops. Not sure how that made it past even my rudimentary compile > > > > testing. > > > > > > > > > > + > > > > > > +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? 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. 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. RP