Re: [PATCH kernel v2] x86/compressed/64: reduce #VC nesting for intercepted CPUID for SEV-SNP guest

Alexey Kardashevskiy
2023-10-03T01:46:03Z

On 1/10/23 20:53, Borislav Petkov wrote:
> On Sun, Oct 01, 2023 at 08:40:30PM +1100, Alexey Kardashevskiy wrote:
>> Ingo says different, who wins? :)
>
> I do: a function gives you type checking - a macro doesn't.

The macro is a wrapper for the sev_es_ghcb_hv_call() function with type
checking.

>>> Then, it should be defined only in sev-shared.c for now.
>>
>> sev-shared.c makes me sad. Including .c is not ... nice,
>
> There's a point in doing things this way.
>
>> I would avoid adding stuff to it at any cost.
>
> Care to give a technical argument why or is it just general sadness?
> Because I don't care about non-technical sentiments.

No it is not technical, it is my ignorance :)

For example why inat.c/insn.c are included and not linked? Cannot linux
compile arch/x86/lib/ files twice into two different .o, for compressed
and running kernels? Is not more logical place for sev-shared.c in
arch/x86/lib/sev.c?

>>> Furthermore, it should not be called "rdmsr" or so but something like
>>>
>>> ghcb_prot_read_msr()
>>>
>>> or so to denote that it is using the GHCB protocol to read the MSR. I'm
>>> sure it'll gain more users with time.
>>
>> What is "prot" going to signify?
>
> "... or so to denote that it is using the GHCB protocol..."
> ^^^^^^^^
>
> it is right there.

Ah right. I am used (after some grepping - not just me) to "prot" ==
"protected", "protocol" would be "proto". imho not needed here but alright.

>> And what about Tom's "x86/sev: Fix SNP CPUID requests to the hypervisor",
>> are you taking that one or I have to repost this one and the Tom's patch?
>
> Yes, use this branch:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git/log/?h=tip-x86-urgent

Oh cool, thanks!

> Thx.
>

--
Alexey