From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3E70D39AEB; Sat, 24 Aug 2024 16:57:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1724518648; cv=none; b=lA+YreZAXi5gQyaqxkZV4aHTSkqvBOfXLqMEAaIDQfmLfm4Upwx7GK2R+dZzmodWFkBnVJQhOg24HiJiBoVxbAUWTZ4C2n2tC4piig2QSVEDg6C0P02BZPGRLOjRptLYkSk5TE79c9/iHEI6XV0t5Rn30yxKNcNs7ZxTLKJp+pk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1724518648; c=relaxed/simple; bh=fZXoHykcvD1A1JFjEQWQzA8RfT1FLb1kSJXWvNQuTSA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=URcmqhs+AB+ONlFJRHKSzN9h+BmEOsionUFpenj+Zn5SUArIGAT/QKiMLNg07QS2HaMnrCx9qQU2Vf12Lhvdw23d7XYD1QRuL31Xt+P7XOJIOwD3oG186mN2AKBggJ3RserJW8Kmf4THSQQqfi4ZMb97BskSolIgYaGuJHGFWeo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=faEd3C6x; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="faEd3C6x" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 19277C32781; Sat, 24 Aug 2024 16:57:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1724518647; bh=fZXoHykcvD1A1JFjEQWQzA8RfT1FLb1kSJXWvNQuTSA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=faEd3C6xk3bB7/IzcZTbthHs2go8i2t8IzxJbgykL8HKT7I1Cj30ifR1rdfbF45+g Xrurn92tq4+O3tvZGh9+E4N0SrITO6hNo608f24CAFL2w8+s94I8EdvfcxDsdNm8ot Bc5vacQ6lB2cE3mOXSvTGaWOePNyc9V7Gs8iGC/tAhkST47dOsItJHz9kjoc8BG/Yy VUSaNfMcaRuhZ3nlshNWMHCIOXpRyhl2UXGJkot63db3C/KSql0sul34SXMPELXrGD ZtYuV+N+tGWTtEN4m+cl1l7WLqR2SQU6vsDP1Gdw87/lejwxOS2ufAqkEj17XIqnR3 5JGiL0AHsoPgw== Date: Sat, 24 Aug 2024 18:57:20 +0200 From: Alexey Gladkov To: "Kirill A. Shutemov" Cc: linux-kernel@vger.kernel.org, linux-coco@lists.linux.dev, Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Andrew Morton , Yuan Yao , Geert Uytterhoeven , Yuntao Wang , Kai Huang , Baoquan He , Oleg Nesterov , cho@microsoft.com, decui@microsoft.com, John.Starks@microsoft.com Subject: Re: [PATCH v4 6/6] x86/tdx: Implement movs for MMIO Message-ID: References: <9320e721e609e55a020d3eb98f48fc856371c561.1724248680.git.legion@kernel.org> Precedence: bulk X-Mailing-List: linux-coco@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Thu, Aug 22, 2024 at 11:28:14AM +0300, Kirill A. Shutemov wrote: > On Wed, Aug 21, 2024 at 04:24:38PM +0200, Alexey Gladkov wrote: > > From: "Alexey Gladkov (Intel)" > > > > Please capitalize MOVS in the subject. > > > Add emulation of the MOVS instruction on MMIO regions. MOVS emulation > > consists of dividing it into a series of read and write operations, > > which in turn will be validated separately. > > Commit message is pretty sparse. I think we need to elaborate on the > similarities and differences with SEV implementation. Locking context > difference is important. Agree. > > diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h > > index a75a07f4931f..45136b1b02cc 100644 > > --- a/arch/x86/include/asm/processor.h > > +++ b/arch/x86/include/asm/processor.h > > @@ -503,6 +503,10 @@ struct thread_struct { > > struct thread_shstk shstk; > > #endif > > > > +#ifdef CONFIG_INTEL_TDX_GUEST > > + unsigned long mmio_emul; > > +#endif > > + > > /* Floating point and extended processor state */ > > struct fpu fpu; > > /* > > Hm. Do we need to track exact target address in the thread struct? > Wouldn't be single bit be enough to allow MMIO to userspace address from a > kernel regs->ip? The flag will identify that a nested exception happened, but it will not be clear which address cause it. Perhaps you are right and this approach is unnecessarily paranoid. > There is space for the flag next to iopl_warn. Yes, I can use just a flag to identify a nested exception. -- Rgrds, legion