Messages in this thread | | | Date | Tue, 3 Oct 2023 12:45:48 +1100 | Subject | Re: [PATCH kernel v2] x86/compressed/64: reduce #VC nesting for intercepted CPUID for SEV-SNP guest | From | Alexey Kardashevskiy <> |
| |
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
| |