[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <611a387b-ba7e-46d7-b6bf-84dc6c037d33@redhat.com>
Date: Fri, 17 May 2024 19:37:38 +0200
From: Paolo Bonzini <pbonzini@...hat.com>
To: Dave Hansen <dave.hansen@...el.com>,
"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
Sean Christopherson <seanjc@...gle.com>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
Borislav Petkov <bp@...en8.de>, x86@...nel.org,
"H. Peter Anvin" <hpa@...or.com>, "K. Y. Srinivasan" <kys@...rosoft.com>,
Haiyang Zhang <haiyangz@...rosoft.com>, Wei Liu <wei.liu@...nel.org>,
Dexuan Cui <decui@...rosoft.com>, Josh Poimboeuf <jpoimboe@...nel.org>,
Peter Zijlstra <peterz@...radead.org>
Cc: linux-coco@...ts.linux.dev, linux-kernel@...r.kernel.org,
linux-hyperv@...r.kernel.org
Subject: Re: [PATCH 03/20] x86/tdx: Convert port I/O handling to use new
TDVMCALL macros
On 5/17/24 17:28, Dave Hansen wrote:
> On 5/17/24 07:19, Kirill A. Shutemov wrote:
>> static inline void tdx_io_out(int size, u16 port, u32 value)
>> {
>> - struct tdx_module_args args = {
>> - .r10 = TDX_HYPERCALL_STANDARD,
>> - .r11 = hcall_func(EXIT_REASON_IO_INSTRUCTION),
>> - .r12 = size,
>> - .r13 = 1,
>> - .r14 = port,
>> - .r15 = value,
>> - };
>> -
>> - __tdx_hypercall(&args);
>> + TDVMCALL_0(hcall_func(EXIT_REASON_IO_INSTRUCTION),
>> + size, TDX_PORT_WRITE, port, value);
>> }
>
> I actually really like the self-documenting nature of the structures. I
> don't think it's a win if this is where the lines-of-code savings comes
> from.
>
It's just a tradeoff. For example someone could well have written
#define TDVMCALL_0(reason, a1, a2, a3, a4) \
do { \
struct tdx_module_args args = {
.r10 = TDX_HYPERCALL_STANDARD,
.r11 = reason,
.r12 = a1,
.r13 = a2,
.r14 = a3,
.r15 = a4,
__tdx_hypercall(&args);
} while(0)
even with the current __tdx_hypercall() implementation.
I agree that TDVMCALL_x is somewhat less legible; on the other hand it
highlights that these TDVMCALLs all have a common convention for passing
parameters / retrieving results, and reduces the potential for silly typos.
This is also why I asked about the different approaches for TDCALL vs.
TDVMCALL. Given that there are only a handful of appearances for
tdvmcall_trampoline, maybe the best of both worlds is just to inline the
whole thing? This way the code in the macros matches the parameter
passing convention of the GHCI.
Paolo
Powered by blists - more mailing lists