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 509ECC433F5 for ; Mon, 21 Mar 2022 17:23:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1351796AbiCURYZ (ORCPT ); Mon, 21 Mar 2022 13:24:25 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50494 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1349308AbiCURYU (ORCPT ); Mon, 21 Mar 2022 13:24:20 -0400 Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 220208EB45 for ; Mon, 21 Mar 2022 10:22:54 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id r22so20844570ljd.4 for ; Mon, 21 Mar 2022 10:22:53 -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=ZZT8+TFC23/AaV+DRFsEWiZYsV60D0EaygpL7J9asyY=; b=l3xYWkl9rDrcVXwTo8URDFqpjnwf5HDy7Rm/hS6hrfmTQimfNuobTHqbU5ws2hXyYy vJLDTsN6bBVSys185PpX+YXy3kL9Tn2QDvQ0fuladCkxw5Pqg92by1vxDJxtARzJmIDQ Sq5cdXBFx6st3cbAF4/8MscBYdVazgz/vZUaJ7iNGzWQmlx/REEgIS6FZwmCj0aGHpOT YT/wAuYvydl5iskA27eSCQ8kS2eCxpTs16k3/XEKg2u/YwnLhmoq0e3oHxM8qG+JP0rR pHTm/S1dSM5BG4cTDagrDX7N2QOcYSgujZih1IwuIU+9gPX5jswVe0siECbqSKA6aoVa WDlA== 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=ZZT8+TFC23/AaV+DRFsEWiZYsV60D0EaygpL7J9asyY=; b=clcaicC7uf7nYgfodhCeq1POg7jvZZkS8Peb8Ry/aaQEKz4TRkrIyIAcjjGQo053vr pPi8MTJfMosdorUNqe8WbhO/fsroml3Zwfwo7DHlI7XJOTApBVCNNyJM2G4aK8UNjM5d iLx2RNHHj5+lB7wauu4YvmKoYKC5GgWR7Z2bRWk2FeR+3BGv77RAEFhucnNgyjPdFHfc 5NJ+kn3mmKzmkUbS3MinKglRz+hpFzTQa+/GE5EddpAKsTm8NU4xVa//lG5DiTQvsuiw II3G2ZZ2t0fQR+xJn3xtM/l641/Pj/VfYycBpVVrmqNh/Vnj1nTZ4deaAxvcMElf4c3m 6GiA== X-Gm-Message-State: AOAM533Fk/HvJsTfFAipzKixm1nHmM6LoI5CU+bXCZCHP2y8UYQ56Cp+ OO9D8auAVKr9Nkroj8mkwq+0xD9QGSvaVfHOjylT91ZUV+0= X-Google-Smtp-Source: ABdhPJwd+VJrkswex1WkGk+m0EmD/YTPqK14jcWtgSCwua815oFulCrxMjof6yeDvJBcB/qOMdMbjGCOvsCPx0v39mc= X-Received: by 2002:a2e:9e81:0:b0:248:7c35:385a with SMTP id f1-20020a2e9e81000000b002487c35385amr16519097ljk.527.1647883369900; Mon, 21 Mar 2022 10:22:49 -0700 (PDT) MIME-Version: 1.0 References: <20220321150214.1895231-1-pgonda@google.com> In-Reply-To: From: Peter Gonda Date: Mon, 21 Mar 2022 11:22:38 -0600 Message-ID: Subject: Re: [PATCH] Add KVM_EXIT_SHUTDOWN metadata for SEV-ES To: Paolo Bonzini Cc: kvm list , Borislav Petkov , Tom Lendacky , Brijesh Singh , Joerg Roedel , Marc Orr , 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 11:08 AM Paolo Bonzini wrote: > > On 3/21/22 16:42, Peter Gonda wrote: > > On Mon, Mar 21, 2022 at 9:27 AM Paolo Bonzini wrote: > >> > >> On 3/21/22 16:02, Peter Gonda wrote: > >>> SEV-ES guests can request termination using the GHCB's MSR protocol. See > >>> AMD's GHCB spec section '4.1.13 Termination Request'. Currently when a > >>> guest does this the userspace VMM sees an KVM_EXIT_UNKNOWN (-EVINAL) > >>> return code from KVM_RUN. By adding a KVM_EXIT_SHUTDOWN_ENTRY to kvm_run > >>> struct the userspace VMM can clearly see the guest has requested a SEV-ES > >>> termination including the termination reason code set and reason code. > >>> > >>> Signed-off-by: Peter Gonda > >>> Cc: Borislav Petkov > >>> Cc: Tom Lendacky > >>> Cc: Brijesh Singh > >>> Cc: Joerg Roedel > >>> Cc: Marc Orr > >>> Cc: Sean Christopherson > >>> Cc: kvm@vger.kernel.org > >>> Cc: linux-kernel@vger.kernel.org > >> > >> Looks good, but it has to also add a capability. > > > > Thanks for the quick review! Just so I understand. I should add > > KVM_CAP_SEV_TERM or something, then if that has been enabled do the > > new functionality, else keep the old functionality? > > No, much simpler; just something for which KVM_CHECK_EXTENSION returns > 1, so that userspace knows that there is a "shutdown" member to be > filled by KVM_EXIT_SHUTDOWN. e.g. KVM_CAP_EXIT_SHUTDOWN_REASON. Makes sense, thanks for help. Will do for V2. > > Paolo >