From: Sean Christopherson <seanjc@google.com>
To: Melody Wang <huibo.wang@amd.com>
Cc: LKML <linux-kernel@vger.kernel.org>, X86 ML <x86@kernel.org>,
Paolo Bonzini <pbonzini@redhat.com>,
Tom Lendacky <thomas.lendacky@amd.com>, KVM <kvm@vger.kernel.org>,
Pavan Kumar Paluri <papaluri@amd.com>
Subject: Re: [PATCH v2] KVM: SVM: Convert plain error code numbers to defines
Date: Mon, 2 Dec 2024 16:11:25 -0800 [thread overview]
Message-ID: <Z05MrWbtZQXOY2qk@google.com> (raw)
In-Reply-To: <20241202214032.350109-1-huibo.wang@amd.com>
On Mon, Dec 02, 2024, Melody Wang wrote:
> Convert VMGEXIT SW_EXITINFO1 codes from plain numbers to proper defines.
>
> No functionality changed.
>
> Signed-off-by: Melody Wang <huibo.wang@amd.com>
> Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
> Reviewed-by: Pavan Kumar Paluri <papaluri@amd.com>
> ---
> arch/x86/include/asm/sev-common.h | 8 ++++++++
> arch/x86/kvm/svm/sev.c | 12 ++++++------
> arch/x86/kvm/svm/svm.c | 2 +-
> 3 files changed, 15 insertions(+), 7 deletions(-)
>
> diff --git a/arch/x86/include/asm/sev-common.h b/arch/x86/include/asm/sev-common.h
> index 98726c2b04f8..01d4744e880a 100644
> --- a/arch/x86/include/asm/sev-common.h
> +++ b/arch/x86/include/asm/sev-common.h
> @@ -209,6 +209,14 @@ struct snp_psc_desc {
>
> #define GHCB_RESP_CODE(v) ((v) & GHCB_MSR_INFO_MASK)
>
> +/*
> + * Error codes of the GHCB SW_EXITINFO1 related to GHCB input that can be
> + * communicated back to the guest
> + */
> +#define GHCB_HV_RESP_SUCCESS 0
> +#define GHCB_HV_RESP_ISSUE_EXCEPTION 1
> +#define GHCB_HV_RESP_MALFORMED_INPUT 2
> +
> /*
> * Error codes related to GHCB input that can be communicated back to the guest
> * by setting the lower 32-bits of the GHCB SW_EXITINFO1 field to 2.
> diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
> index 72674b8825c4..e7db7a5703b7 100644
> --- a/arch/x86/kvm/svm/sev.c
> +++ b/arch/x86/kvm/svm/sev.c
> @@ -3433,7 +3433,7 @@ static int sev_es_validate_vmgexit(struct vcpu_svm *svm)
> dump_ghcb(svm);
> }
>
> - ghcb_set_sw_exit_info_1(svm->sev_es.ghcb, 2);
> + ghcb_set_sw_exit_info_1(svm->sev_es.ghcb, GHCB_HV_RESP_MALFORMED_INPUT);
> ghcb_set_sw_exit_info_2(svm->sev_es.ghcb, reason);
Hmm, IMO, open coding literals in multiple locations is a symptom of not providing
helpers. From a certain (slightly warped) perspective, setting exit_info_1 vs.
exit_info_2 is just weird version of an open coded literal.
Rather than provide macros (or probably in addition to), what if we provide helpers
to set the error code and the payload? That would also ensure KVM sets both '1'
and '2' fields. E.g. in sev_handle_vmgexit()'s SVM_VMGEXIT_AP_JUMP_TABLE path,
setting '2' but not '1' is mildly confusing at first glance, because it takes some
staring to understand that's it's NOT a failure path. Ditto for
sev_vcpu_deliver_sipi_vector().
And IMO, not having to parse input parameters to understand success vs. failure
usually makes code easier to read.
E.g. something like this? Definitely feel free to suggest better names.
static inline void svm_vmgexit_set_return_code(struct vcpu_svm *svm,
u64 response, u64 data)
{
ghcb_set_sw_exit_info_1(svm->sev_es.ghcb, response);
ghcb_set_sw_exit_info_2(svm->sev_es.ghcb, data);
}
static inline void svm_vmgexit_inject_exception(struct vcpu_svm *svm, u8 vector)
{
u64 data = SVM_EVTINJ_VALID | SVM_EVTINJ_TYPE_EXEPT | vector;
svm_vmgexit_set_return_code(svm, GHCB_HV_RESP_ISSUE_EXCEPTION, data);
}
static inline void svm_vmgexit_bad_input(struct vcpu_svm *svm, u64 suberror)
{
svm_vmgexit_set_return_code(svm, GHCB_HV_RESP_MALFORMED_INPUT, suberror);
}
static inline void svm_vmgexit_success(struct vcpu_svm *svm, u64 data)
{
svm_vmgexit_set_return_code(svm, GHCB_HV_RESP_SUCCESS, data);
}
next prev parent reply other threads:[~2024-12-03 0:11 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-02 21:40 [PATCH v2] KVM: SVM: Convert plain error code numbers to defines Melody Wang
2024-12-03 0:11 ` Sean Christopherson [this message]
2024-12-03 21:46 ` Melody (Huibo) Wang
2024-12-04 0:50 ` Sean Christopherson
2024-12-04 23:20 ` Melody (Huibo) Wang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Z05MrWbtZQXOY2qk@google.com \
--to=seanjc@google.com \
--cc=huibo.wang@amd.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=papaluri@amd.com \
--cc=pbonzini@redhat.com \
--cc=thomas.lendacky@amd.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox