Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp1051032ybk; Wed, 20 May 2020 20:05:01 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwtqd4XPVUyXxp05OIvSOiBfJ959yRpUP3/ub9TrHYxXKiyNiig9qOFBWA+Pl9AMyjB1WRz X-Received: by 2002:a17:906:d85:: with SMTP id m5mr1685929eji.251.1590030301606; Wed, 20 May 2020 20:05:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1590030301; cv=none; d=google.com; s=arc-20160816; b=DjIGif+1dF5MB+TcQgf4v0b4b9J9M1LnVHgEjmJODF0r8g1z1f0l3rHtNlVg5nKtDp kXqW+j8cNQRuxoFZNxo+imhCBjwOL2qGYaT83zszoiX8so69gklAuus9fFkvamdWHGfB H8q2D5Mjf9KELuH6QoeWskvab6cBqQrWb6lZ/gCw6rpcW4hXA2wMNgR5p0e2lFTiIwWb xmpmvYejIdX7ZGpjpHT+W1kafk4irsCBVSNyBlUWPrrWxssLXTfwCur6KuUI+l0qdPF2 olopOIRRs7n01HJWUPNjLiOaHXotPXCKabJaOu1DBXCnTVS4F3CLp2Ra5SmoCuQWc42D UNJQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=kMS8JJGzm0fWTOcba96a0ELQUsfkV8lwswRJcmpjgcU=; b=tbYXyKs2WE9K2vWBV2S0zBvq3JBrst+cP2t5hR0SFOlG6acRcde4ABVB4+83aAtuZA dENRQffrdFwEkiQX8jqUoUJoNOX7pW70bAqIVuKUEXwyAZH5C8rwCU5d3E1vgNWjbudZ /ni5LwEFnhrgmyAi0joByTjFbEv7MBr3o0hupEqU5OzJKw4SwjZ2k80WqxkqTZevflYT EDkKOln4mqkIEo1Wa1ka1Kf2YlUMsRpXmslmHrbRGE8/XrD5vzjB3iOSNnylBVQaG/CD Ujm/+1Oe/qrws/7ggDchMZVXChl9yzPhfkzTIv+/G7RmQiLgqLBZ9FK+6KR2qop/5NRP k+uQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id j18si2404577edq.98.2020.05.20.20.04.38; Wed, 20 May 2020 20:05:01 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727962AbgEUDBD (ORCPT + 99 others); Wed, 20 May 2020 23:01:03 -0400 Received: from 19.mo4.mail-out.ovh.net ([87.98.179.66]:33096 "EHLO 19.mo4.mail-out.ovh.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726861AbgEUDBD (ORCPT ); Wed, 20 May 2020 23:01:03 -0400 X-Greylist: delayed 32998 seconds by postgrey-1.27 at vger.kernel.org; Wed, 20 May 2020 23:01:02 EDT Received: from player732.ha.ovh.net (unknown [10.108.57.150]) by mo4.mail-out.ovh.net (Postfix) with ESMTP id 0A5A523673D for ; Wed, 20 May 2020 19:33:09 +0200 (CEST) Received: from kaod.org (lns-bzn-46-82-253-208-248.adsl.proxad.net [82.253.208.248]) (Authenticated sender: groug@kaod.org) by player732.ha.ovh.net (Postfix) with ESMTPSA id F18101274FFBC; Wed, 20 May 2020 17:33:01 +0000 (UTC) Authentication-Results: garm.ovh; auth=pass (GARM-104R00501e830cb-d745-4bc0-ad5d-5f7e91f631ff,D4AE9CB3A4750E3488E7135F1D4D455A9A9A4933) smtp.auth=groug@kaod.org Date: Wed, 20 May 2020 19:32:59 +0200 From: Greg Kurz To: Laurent Dufour Cc: kvm-ppc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, paulus@samba.org, mpe@ellerman.id.au, sukadev@linux.ibm.com, linuxram@us.ibm.com Subject: Re: [PATCH] KVM: PPC: Book3S HV: relax check on H_SVM_INIT_ABORT Message-ID: <20200520193259.0b66db32@bahia.lan> In-Reply-To: <20200520165110.71020-1-ldufour@linux.ibm.com> References: <20200520165110.71020-1-ldufour@linux.ibm.com> X-Mailer: Claws Mail 3.17.4 (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Ovh-Tracer-Id: 7626001547735570884 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduhedruddtledgudduvdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkjghfofggtgfgsehtjeertdertddvnecuhfhrohhmpefirhgvghcumfhurhiiuceoghhrohhugheskhgrohgurdhorhhgqeenucggtffrrghtthgvrhhnpeehkefhtdehgeehheejledufeekhfdvleefvdeihefhkefhudffhfeuuedvffdthfenucfkpheptddrtddrtddrtddpkedvrddvheefrddvtdekrddvgeeknecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhpqdhouhhtpdhhvghlohepphhlrgihvghrjeefvddrhhgrrdhovhhhrdhnvghtpdhinhgvtheptddrtddrtddrtddpmhgrihhlfhhrohhmpehgrhhouhhgsehkrghougdrohhrghdprhgtphhtthhopehlihhnuhigqdhkvghrnhgvlhesvhhgvghrrdhkvghrnhgvlhdrohhrgh Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 20 May 2020 18:51:10 +0200 Laurent Dufour wrote: > The commit 8c47b6ff29e3 ("KVM: PPC: Book3S HV: Check caller of H_SVM_* > Hcalls") added checks of secure bit of SRR1 to filter out the Hcall > reserved to the Ultravisor. > > However, the Hcall H_SVM_INIT_ABORT is made by the Ultravisor passing the > context of the VM calling UV_ESM. This allows the Hypervisor to return to > the guest without going through the Ultravisor. Thus the Secure bit of SRR1 > is not set in that particular case. > > In the case a regular VM is calling H_SVM_INIT_ABORT, this hcall will be > filtered out in kvmppc_h_svm_init_abort() because kvm->arch.secure_guest is > not set in that case. > Why not checking vcpu->kvm->arch.secure_guest then ? > Fixes: 8c47b6ff29e3 ("KVM: PPC: Book3S HV: Check caller of H_SVM_* Hcalls") > Signed-off-by: Laurent Dufour > --- > arch/powerpc/kvm/book3s_hv.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c > index 93493f0cbfe8..eb1f96cb7b72 100644 > --- a/arch/powerpc/kvm/book3s_hv.c > +++ b/arch/powerpc/kvm/book3s_hv.c > @@ -1099,9 +1099,7 @@ int kvmppc_pseries_do_hcall(struct kvm_vcpu *vcpu) > ret = kvmppc_h_svm_init_done(vcpu->kvm); > break; > case H_SVM_INIT_ABORT: > - ret = H_UNSUPPORTED; > - if (kvmppc_get_srr1(vcpu) & MSR_S) > - ret = kvmppc_h_svm_init_abort(vcpu->kvm); or at least put a comment to explain why H_SVM_INIT_ABORT doesn't have the same sanity check as the other SVM hcalls. > + ret = kvmppc_h_svm_init_abort(vcpu->kvm); > break; > > default: