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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7D3C6C433EF for ; Fri, 25 Mar 2022 15:35:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1376708AbiCYPgZ (ORCPT ); Fri, 25 Mar 2022 11:36:25 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49342 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1377352AbiCYPdZ (ORCPT ); Fri, 25 Mar 2022 11:33:25 -0400 Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E6A952D1E8 for ; Fri, 25 Mar 2022 08:29:00 -0700 (PDT) Received: by mail-lf1-x133.google.com with SMTP id h7so14001413lfl.2 for ; Fri, 25 Mar 2022 08:29:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QPocrmqkuGYHnUVRsDZ/TbHe19zETFDOn27Vxny6QCI=; b=NoKTAx+GgAdqOfHToR+2NJ4UdtSN0mm4Tiu7cxkqcQZtXSOtizFo+YQNtguTvNiTmP 9APy8PjqvWRslGk9feJMbBLaUCDojNH9pMCZI57GUJ//r4APse05WQqFon6BG8iThpUo g8Ci2br9eGFDcFOLMRmzAyw/hWsqw7ecyDZXnilV1Ko9h1OtIZhgMZPZRRMEFRYwiWFr 8r2KQXyeDlTh6eqiVYp9AZpgjZB5Fnjs3hYtMrokYSLBaYCVoJiE00zqnakqCQ5N7zXi oG1I/OCrDfwt8EoRs99vAdJU+hjtm59SrJNSZ4uHdN5AVtdOUrVIvE5UCittHYJeQF0s NhLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QPocrmqkuGYHnUVRsDZ/TbHe19zETFDOn27Vxny6QCI=; b=PASzDOI3Tc6FKYR8T9J5jj1+rp6koRIRaKnGK9+nJjFLB/Jlg5yR2ahedD18y7Vtud vEX9UFWmxsJQrbns03DRnesNMk2K7R4BLU7uOSK+dmc8p5Re1Nf7z2fBZnAnQvb0A1HQ SLV75hPNtQqS3nrYInOp6nq6UK8wZrmJPvc4Pn8G/hpFZ+ZSANrAyzOGqG8Y3d6xnUy7 52LI5Qgw5XkbAfkf4IKsE2Cuc4TNu+4+CmOUtWD+PxQTs/ax2ftINu1ZcgE//xgR0pbi hskoN7BxhWFcyn2JWNcA/V9ZGgYXR9QOLy86tsaWYz1LaGQPRF8SRnNik9Do9kkzuxPJ ERmA== X-Gm-Message-State: AOAM5333tsXinyA7ne8lJjyLtIa/iGiZ+PxNgMok88J8xjn6LpyD6FEJ mj87nYDu59OYXYarLH6GZcGkLhV38BwB/LoHgDOZdQ== X-Google-Smtp-Source: ABdhPJwajANP/u7dvP2rPWqqB9wMD9F7TC7XMC4AiQxoD4/abx/UvRQZWo382ah99ciAEHJzTMSSX94FSkDjdVNzRRU= X-Received: by 2002:a05:6512:15a3:b0:44a:54eb:937e with SMTP id bp35-20020a05651215a300b0044a54eb937emr8040694lfb.456.1648222138745; Fri, 25 Mar 2022 08:28:58 -0700 (PDT) MIME-Version: 1.0 References: <20220321150214.1895231-1-pgonda@google.com> In-Reply-To: From: Peter Gonda Date: Fri, 25 Mar 2022 09:28:47 -0600 Message-ID: Subject: Re: [PATCH] Add KVM_EXIT_SHUTDOWN metadata for SEV-ES To: Marc Orr Cc: kvm list , Borislav Petkov , Tom Lendacky , Brijesh Singh , Joerg Roedel , Sean Christopherson , LKML Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 21, 2022 at 1:45 PM Marc Orr wrote: > > On Mon, Mar 21, 2022 at 11:08 AM Peter Gonda wrote: > > > > > > diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c > > > > index 75fa6dd268f0..5f9d37dd3f6f 100644 > > > > --- a/arch/x86/kvm/svm/sev.c > > > > +++ b/arch/x86/kvm/svm/sev.c > > > > @@ -2735,8 +2735,13 @@ static int sev_handle_vmgexit_msr_protocol(struct vcpu_svm *svm) > > > > pr_info("SEV-ES guest requested termination: %#llx:%#llx\n", > > > > reason_set, reason_code); > > > > > > > > - ret = -EINVAL; > > > > - break; > > > > + vcpu->run->exit_reason = KVM_EXIT_SHUTDOWN; > > > > + vcpu->run->shutdown.reason = KVM_SHUTDOWN_SEV_TERM; > > > > + vcpu->run->shutdown.ndata = 2; > > > > + vcpu->run->shutdown.data[0] = reason_set; > > > > + vcpu->run->shutdown.data[1] = reason_code; > > > > + > > > > + return 0; > > > > > > Maybe I'm missing something, but don't we want to keep returning an error? > > > > > > rationale: Current behavior: return -EINVAL to userpsace, but > > > userpsace cannot infer where the -EINVAL came from. After this patch: > > > We should still return -EINVAL to userspace, but now userspace can > > > parse this new info in the KVM run struct to properly terminate. > > > > > > > I removed the error return code here since an SEV guest may request a > > termination due to no fault of the host at all. This is now inline > > with any other shutdown requested by the guest. I don't have a strong > > preference here but EINVAL doesn't seem correct in all cases, do > > others have any thoughts on this? > > Makes sense. Yeah, let's see if others have an opinion. Otherwise, I'm > fine either way. Now that you mention it, returning an error to > userspace when the guest triggered the self-termination, and could've > done so for reasons outside the host's control, is a little odd. But > at the same time, it's just as likely that the guest is > self-terminating due to a host-side error. So I guess it's not clear > whether returning an error here is "right" or "wrong". Since no one has expressed a strong opinion have have left this part of the patch unchanged in the V2. Happy to revise again if people prefer something else.