From: Sean Christopherson <seanjc@google.com>
To: "Melody (Huibo) 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: Tue, 3 Dec 2024 16:50:03 -0800 [thread overview]
Message-ID: <Z0-nO-iyICRy_m5S@google.com> (raw)
In-Reply-To: <c09a99e8-913f-4a86-ba0b-c64d5cdcfb2e@amd.com>
On Tue, Dec 03, 2024, Melody (Huibo) Wang wrote:
> Hi Sean,
>
> On 12/2/2024 4:11 PM, Sean Christopherson wrote:
>
> >
> > 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);
> > }
> >
> If I make this function more generic where the exit info is set for both KVM
> and the guest, then maybe I can write something like this:
I like the idea, but I actually think it's better to keep the guest and host code
separate in the case, because the guest code should actually set a triple, e.g.
static __always_inline void sev_es_vmgexit_set_exit_info(struct ghcb *ghcb,
u64 exit_code,
u64 exit_info_1,
u64 exit_info_2)
{
ghcb_set_sw_exit_code(ghcb, exit_code);
ghcb_set_sw_exit_info_1(ghcb, exit_info_1);
ghcb_set_sw_exit_info_2(ghcb, exit_info_2);
}
I'm not totally opposed to sharing code, but I think it will be counter-productive
in this specific case. E.g. the guest version needs to be __always_inline so that
it can be used in noinstr code.
> void ghcb_set_exit_info(struct ghcb *ghcb,
> u64 info1, u64 info2)
> {
> ghcb_set_sw_exit_info_1(ghcb, info1);
> ghcb_set_sw_exit_info_2(ghcb, info2);
>
> }
> This way we can address every possible case that sets the exit info - not only KVM.
>
> And I am not sure about the wrappers for each specific case because we will
> have too many, too specific small functions, but if you want them I can add
> them.
I count three. We have far, far more wrappers VMX's is_exception_n(), and IMO
those wrappers make the code significantly more readable.
next prev parent reply other threads:[~2024-12-04 0:50 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
2024-12-03 21:46 ` Melody (Huibo) Wang
2024-12-04 0:50 ` Sean Christopherson [this message]
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=Z0-nO-iyICRy_m5S@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.