Received: by 2002:a05:6a10:eb17:0:0:0:0 with SMTP id hx23csp535540pxb; Thu, 9 Sep 2021 06:38:21 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw30fHHXlO3ekacjg5uxBSveeTq2Ypx6Ddjo+FoxGGizMOde8bDKNPXXy/gk8DY9mB8Yoqd X-Received: by 2002:a05:6602:2c05:: with SMTP id w5mr2780972iov.160.1631194701513; Thu, 09 Sep 2021 06:38:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1631194701; cv=none; d=google.com; s=arc-20160816; b=D3RuwzakytcXzJMvjua1fHgiDJNQniTVmSrevCJB3ioCv4BZDNEnbNkyFE9KBGgoqP tmKx3sQN7IOFTwvWLwhTFJViYtL4hDbftsffdcUJeRsvj08i9umpGh6qQvvIzJJ73OZN kDvi0q2QXL5l14Q0DDx67dKKkO4Oo2uTqOz56RST2pyvjQU9Ok48kBMD6qbp70bN/1Si hS25E3EN1MczE2LLO8k4AX9T74ZG2KQAZO+pm/CyZz03K/o/ZpIvUAPGq4jF4EALffsK DAOV6yoRiZOnfw4WYQ3ClQUNN5yQQr+o9y7PvIFsDgCtArlIxOvfULTeBP0GBZ4r0Ygb z3dw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=ZVvDTp9F6iy7NRW31DyMlDjcTsDe+b6yHooJN28PMl0=; b=tTG1inR0GUajt9doju4+2xpyfCHQpGrNd+FCLtrA7++mwmfuPHG/WtwDlzAbwNVAiL lmLXoDnXtCEnOX5k063LsnqUlFTyMh+6WOiIr8nMJpZyrmvjIqOiiF4BF6ZWDaXd6fu0 axXqdzAG+UUGHAhScNog09VLorv6mHmyqt2+BbeFIHbOWUzcPsqzAb9dS4MHpRGLiEAL 92EiWS+xcKQMirvM9cIVNJ7WfiMfqgMPRaTWmrSKI1rtfcuM+LnHwz1ddVkOCIJUKHFi NfXS7ZJYW5CFSy8g47e+6P420t3wPORa9C2Kj4pqyF4fdsJ/l16LJFO7anqkNa2HChXT qQjg== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=8bytes.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id m14si1735585jac.89.2021.09.09.06.38.07; Thu, 09 Sep 2021 06:38:21 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=8bytes.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348224AbhIINi0 (ORCPT + 99 others); Thu, 9 Sep 2021 09:38:26 -0400 Received: from 8bytes.org ([81.169.241.247]:53392 "EHLO theia.8bytes.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1351087AbhIINeD (ORCPT ); Thu, 9 Sep 2021 09:34:03 -0400 Received: by theia.8bytes.org (Postfix, from userid 1000) id 0D39DD35; Thu, 9 Sep 2021 15:32:50 +0200 (CEST) Date: Thu, 9 Sep 2021 15:32:21 +0200 From: Joerg Roedel To: Sean Christopherson Cc: Paolo Bonzini , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Brijesh Singh , Tom Lendacky , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-coco@lists.linux.dev, Joerg Roedel Subject: Re: [PATCH v2 1/4] KVM: SVM: Get rid of *ghcb_msr_bits() functions Message-ID: References: <20210722115245.16084-1-joro@8bytes.org> <20210722115245.16084-2-joro@8bytes.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Sep 01, 2021 at 09:12:10PM +0000, Sean Christopherson wrote: > On Thu, Jul 22, 2021, Joerg Roedel wrote: > > case GHCB_MSR_TERM_REQ: { > > u64 reason_set, reason_code; > > > > - reason_set = get_ghcb_msr_bits(svm, > > - GHCB_MSR_TERM_REASON_SET_MASK, > > - GHCB_MSR_TERM_REASON_SET_POS); > > - reason_code = get_ghcb_msr_bits(svm, > > - GHCB_MSR_TERM_REASON_MASK, > > - GHCB_MSR_TERM_REASON_POS); > > + reason_set = GHCB_MSR_TERM_REASON_SET(control->ghcb_gpa); > > + reason_code = GHCB_MSR_TERM_REASON(control->ghcb_gpa); > > + > > pr_info("SEV-ES guest requested termination: %#llx:%#llx\n", > > reason_set, reason_code); > > + > > fallthrough; > > Not related to this patch, but why use fallthrough and more importantly, why is > this an -EINVAL return? Why wouldn't KVM forward the request to userspace instead > of returning an opaque -EINVAL? I guess it is to signal an error condition up the call-chain to get the guest terminated, like requested. Regards, Joerg