Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
Date:   Mon, 21 Feb 2022 17:25:43 -0800
From:   Josh Poimboeuf <jpoimboe@redhat.com>
To:     "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Cc:     Tom Lendacky <thomas.lendacky@amd.com>, tglx@linutronix.de,
        mingo@redhat.com, bp@alien8.de, 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, 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: [PATCHv3 16/32] x86/boot: Allow to hook up alternative port I/O
 helpers
Message-ID: <20220222012543.emeoqt4sppwurycj@treble>
References: <20220218161718.67148-1-kirill.shutemov@linux.intel.com>
 <20220218161718.67148-17-kirill.shutemov@linux.intel.com>
 <8bb2e660-f92d-a501-57ea-61138dafed28@amd.com>
 <20220221220233.mbntv342fg2wp7dp@black.fi.intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20220221220233.mbntv342fg2wp7dp@black.fi.intel.com>
Precedence: bulk

On Tue, Feb 22, 2022 at 01:02:33AM +0300, Kirill A. Shutemov wrote:
> On Mon, Feb 21, 2022 at 02:04:33PM -0600, Tom Lendacky wrote:
> > On 2/18/22 10:17, Kirill A. Shutemov wrote:
> > > Port I/O instructions trigger #VE in the TDX environment. In response to
> > > the exception, kernel emulates these instructions using hypercalls.
> > > 
> > > But during early boot, on the decompression stage, it is cumbersome to
> > > deal with #VE. It is cleaner to go to hypercalls directly, bypassing #VE
> > > handling.
> > > 
> > > Add a way to hook up alternative port I/O helpers in the boot stub.
> > 
> > This seems like a lot of churn in order to get this all working without
> > taking a #VE.
> 
> Well, it evolved from more concise (but also more hacky) implementation:
> 
> https://lore.kernel.org/all/20211214150304.62613-11-kirill.shutemov@linux.intel.com
> 
> > How cumbersome is it to get #VE handling working in the decompression
> > stage? Can you build on any of the support that was added to handle #VC?
> 
> We definitely can.
> 
> But I still think exception-based implementation is inherently more
> fragile. I would rather stick with this.

At least from reading the commit message it's not self-evident why #VE
handling would be worse, especially since there's already #VC support in
boot.  It would help to give more info about that in the commit message.

The current approach also seems fragile, doesn't it require all future
code to remember to not do i/o directly?  How do we make sure that
doesn't happen going forward?

How does it fail if some code accidentally does i/o directly?  Or
triggers #VE some other way?  Is the error understandable and
actionable?

-- 
Josh