Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Sat, 15 Jan 2022 04:01:55 +0300
From:   "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
To:     Borislav Petkov <bp@alien8.de>
Cc:     tglx@linutronix.de, mingo@redhat.com, dave.hansen@intel.com,
        luto@kernel.org, peterz@infradead.org,
        sathyanarayanan.kuppuswamy@linux.intel.com, aarcange@redhat.com,
        ak@linux.intel.com, dan.j.williams@intel.com, david@redhat.com,
        hpa@zytor.com, jgross@suse.com, jmattson@google.com,
        joro@8bytes.org, jpoimboe@redhat.com, knsathya@kernel.org,
        pbonzini@redhat.com, sdeep@vmware.com, seanjc@google.com,
        tony.luck@intel.com, vkuznets@redhat.com, wanpengli@tencent.com,
        x86@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 10/26] x86/tdx: Support TDX guest port I/O at
 decompression time
Message-ID: <20220115010155.ss2hnyotw4a3nljf@black.fi.intel.com>
References: <20211214150304.62613-1-kirill.shutemov@linux.intel.com>
 <20211214150304.62613-11-kirill.shutemov@linux.intel.com>
 <YeAuehoOEjUH3vZ3@zn.tnic>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <YeAuehoOEjUH3vZ3@zn.tnic>
Precedence: bulk

On Thu, Jan 13, 2022 at 02:51:54PM +0100, Borislav Petkov wrote:
> On Tue, Dec 14, 2021 at 06:02:48PM +0300, Kirill A. Shutemov wrote:
> > From: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
> > 
> > Port IO triggers a #VE exception in TDX guests.  During normal runtime,
> > the kernel will handle those exceptions for any port IO.
> > 
> > But for the early code in the decompressor, #VE cannot be used because
> > the IDT needed for handling the exception is not set up.
> 							  ... yet.
> 
> Well, we're setting up and IDT twice in
> 
> arch/x86/boot/compressed/idt_64.c
> 
> as early as startup_64 for SEV. And the second stage one
> do_boot_stage2_vc() handles port IO too.
> 
> Can't you hook in your VE handler there too?

We certainly can. But do we want to?

IIUC, SEV has to handle #VC very early to deal with CPUID and covering
port I/O in addition via the exception is a logical step.

We had some back and forth on #VE vs direct hypercalls for port I/O in
decompresser and we settled on direct hypercalls.

Adding all the plumbing for #VE just to deal with port I/O was considered
overkill. And I expect debugging exception infrastructure is harder than
direct hypercalls.

Do you see it differently? Do you want to switch to #VE here?

> > Replace IN/OUT instructions with TDX IO hypercalls by defining helper
> > macros __in/__out and by re-defining them in the decompressor code.
> > Also, since TDX IO hypercall requires an IO size parameter, allow
> > __in/__out macros to accept size as an input parameter.
> 
> Please end function/macro names with parentheses. I think in this
> particular case you wanna say
> 
> "__in*()/__out*() macros"
> 
> When a function is mentioned in the changelog, either the text body or the
> subject line, please use the format 'function_name()'. Omitting the
> brackets after the function name can be ambiguous::
> 
>   Subject: subsys/component: Make reservation_count static
> 
>   reservation_count is only used in reservation_stats. Make it static.
> 
> The variant with brackets is more precise::
> 
>   Subject: subsys/component: Make reservation_count() static
> 
>   reservation_count() is only called from reservation_stats(). Make it
>   static.

Okay, got it.

-- 
 Kirill A. Shutemov