mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Dave Hansen <dave.hansen@intel.com>
To: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	tglx@linutronix.de, mingo@redhat.com, bp@alien8.de,
	luto@kernel.org, peterz@infradead.org
Cc: 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,
	thomas.lendacky@amd.com, brijesh.singh@amd.com, x86@kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCHv4 17/30] x86/tdx: Add port I/O emulation
Date: Thu, 24 Feb 2022 14:43:21 -0800	[thread overview]
Message-ID: <554143b6-36c6-d192-9662-1a5ac6dfa97f@intel.com> (raw)
In-Reply-To: <20220224155630.52734-18-kirill.shutemov@linux.intel.com>

On 2/24/22 07:56, Kirill A. Shutemov wrote:
> From: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
> 
> TDX hypervisors cannot emulate instructions directly. This includes
> port I/O which is normally emulated in the hypervisor. All port I/O
> instructions inside TDX trigger the #VE exception in the guest and
> would be normally emulated there.
> 
> Use a hypercall to emulate port I/O. Extend the
> tdx_handle_virt_exception() and add support to handle the #VE due to
> port I/O instructions.
> 
> String I/O operations are not supported in TDX. Unroll them by declaring
> CC_ATTR_GUEST_UNROLL_STRING_IO confidential computing attribute.
> 
> Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
> Reviewed-by: Andi Kleen <ak@linux.intel.com>
> Reviewed-by: Dan Williams <dan.j.williams@intel.com>
> Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
> ---
>  arch/x86/coco/core.c |  7 +++++-
>  arch/x86/coco/tdx.c  | 54 ++++++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 60 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/coco/core.c b/arch/x86/coco/core.c
> index 9113baebbfd2..5615b75e6fc6 100644
> --- a/arch/x86/coco/core.c
> +++ b/arch/x86/coco/core.c
> @@ -18,7 +18,12 @@ static u64 cc_mask __ro_after_init;
>  
>  static bool intel_cc_platform_has(enum cc_attr attr)
>  {
> -	return false;
> +	switch (attr) {
> +	case CC_ATTR_GUEST_UNROLL_STRING_IO:
> +		return true;
> +	default:
> +		return false;
> +	}
>  }
>  
>  /*
> diff --git a/arch/x86/coco/tdx.c b/arch/x86/coco/tdx.c
> index 15519e498679..2e342760b1d2 100644
> --- a/arch/x86/coco/tdx.c
> +++ b/arch/x86/coco/tdx.c
> @@ -19,6 +19,12 @@
>  #define EPT_READ	0
>  #define EPT_WRITE	1
>  
> +/* See Exit Qualification for I/O Instructions in VMX documentation */
> +#define VE_IS_IO_IN(e)		((e) & BIT(3))
> +#define VE_GET_IO_SIZE(e)	(((e) & GENMASK(2, 0)) + 1)
> +#define VE_GET_PORT_NUM(e)	((e) >> 16)
> +#define VE_IS_IO_STRING(e)	((e) & BIT(4))
> +
>  static struct {
>  	unsigned int gpa_width;
>  	unsigned long attributes;
> @@ -292,6 +298,52 @@ static bool handle_mmio(struct pt_regs *regs, struct ve_info *ve)
>  	return true;
>  }
>  
> +/*
> + * Emulate I/O using hypercall.
> + *
> + * Assumes the IO instruction was using ax, which is enforced
> + * by the standard io.h macros.
> + *
> + * Return True on success or False on failure.
> + */
> +static bool handle_io(struct pt_regs *regs, u32 exit_qual)
> +{
> +	struct tdx_hypercall_args args = {
> +		.r10 = TDX_HYPERCALL_STANDARD,
> +		.r11 = EXIT_REASON_IO_INSTRUCTION,
> +	};
> +	int size, port;
> +	u64 mask;
> +	bool in, ret;
> +
> +	if (VE_IS_IO_STRING(exit_qual))
> +		return false;
> +
> +	in   = VE_IS_IO_IN(exit_qual);
> +	size = VE_GET_IO_SIZE(exit_qual);
> +	port = VE_GET_PORT_NUM(exit_qual);
> +	mask = GENMASK(BITS_PER_BYTE * size, 0);
> +
> +	args.r12 = size;
> +	args.r13 = !in;
> +	args.r14 = port;
> +	args.r15 = in ? 0 : regs->ax;
> +
> +	/*
> +	 * Emulate the I/O read/write via hypercall. More info about
> +	 * ABI can be found in TDX Guest-Host-Communication Interface
> +	 * (GHCI) section titled "TDG.VP.VMCALL<Instruction.IO>".
> +	 */
> +	ret = !__tdx_hypercall(&args, in ? TDX_HCALL_HAS_OUTPUT : 0);
> +	if (!ret || !in)
> +		return ret;
> +
> +	regs->ax &= ~mask;
> +	regs->ax |= ret ? args.r11 & mask : UINT_MAX;
> +
> +	return ret;
> +}


I can't help but think this would be more clear if the in and !in sideds
were separated:

	if (!in) {
		args.r15 = regs->ax;
		ret = !__tdx_hypercall(&args, 0);
	} else {
		args.r15 = 0;
		ret = !__tdx_hypercall(&args, TDX_HCALL_HAS_OUTPUT);
		regs->ax &= ~mask;
		if (ret)
			regs->ax |= args.r11 & mask
		else
			regs->ax |= UINT_MAX;
	}

	return ret;

The ->ax mangling also needs a comment.  It looks like it's trying to
inject -1 when there's a failure.  Even if the roots of this are in the
TDX spec(s), it would be nice to express the intent of this code.

I also really dislike using 'ret' as a bool return type.  Wouldn't this
be about a billion times clearer if 'ret' was renamed to 'success'?

Right now, this code is effectively doing:

	if (!ret)
		return error;

Which is actually functionally correct here.  All other int-typed 'ret'
code in the kernel do this:

	if (ret)
		return error;

which would be functionally _wrong_.  Can you please take mercy on my
little brain an at least make the code look different if it behaves the
opposite from the same literal code in other spots in the kernel?

Heck, even 'bool handled' would be pretty nice.

>  void tdx_get_ve_info(struct ve_info *ve)
>  {
>  	struct tdx_module_output out;
> @@ -347,6 +399,8 @@ static bool virt_exception_kernel(struct pt_regs *regs, struct ve_info *ve)
>  		return handle_cpuid(regs);
>  	case EXIT_REASON_EPT_VIOLATION:
>  		return handle_mmio(regs, ve);
> +	case EXIT_REASON_IO_INSTRUCTION:
> +		return handle_io(regs, ve->exit_qual);
>  	default:
>  		pr_warn("Unexpected #VE: %lld\n", ve->exit_reason);
>  		return false;


  reply	other threads:[~2022-02-24 22:43 UTC|newest]

Thread overview: 88+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-24 15:56 [PATCHv4 00/30] TDX Guest: TDX core support Kirill A. Shutemov
2022-02-24 15:56 ` [PATCHv4 01/30] x86/mm: Fix warning on build with X86_MEM_ENCRYPT=y Kirill A. Shutemov
2022-02-24 16:06   ` Dave Hansen
2022-02-27 22:01   ` Josh Poimboeuf
2022-02-28 16:20     ` Kirill A. Shutemov
2022-02-28 16:40       ` Josh Poimboeuf
2022-02-28 16:51         ` Dave Hansen
2022-02-28 17:11           ` Josh Poimboeuf
2022-03-01  8:48             ` Borislav Petkov
2022-02-24 15:56 ` [PATCHv4 02/30] x86/tdx: Detect running as a TDX guest in early boot Kirill A. Shutemov
2022-02-24 16:16   ` Dave Hansen
2022-02-24 15:56 ` [PATCHv4 03/30] x86/tdx: Provide common base for SEAMCALL and TDCALL C wrappers Kirill A. Shutemov
2022-02-24 16:35   ` Dave Hansen
2022-02-24 23:10     ` Kirill A. Shutemov
2022-02-25  0:41       ` Dave Hansen
2022-02-25 10:39         ` Kai Huang
2022-02-25 15:46         ` Kirill A. Shutemov
2022-02-25 16:12           ` Dave Hansen
2022-02-24 15:56 ` [PATCHv4 04/30] x86/tdx: Add __tdx_module_call() and __tdx_hypercall() helper functions Kirill A. Shutemov
2022-02-24 17:01   ` Dave Hansen
2022-02-24 23:29     ` Kirill A. Shutemov
2022-02-24 15:56 ` [PATCHv4 05/30] x86/tdx: Extend the confidential computing API to support TDX guests Kirill A. Shutemov
2022-02-24 17:54   ` Dave Hansen
2022-02-24 23:54     ` Kirill A. Shutemov
2022-02-25  0:51       ` Dave Hansen
2022-02-24 15:56 ` [PATCHv4 06/30] x86/tdx: Exclude shared bit from __PHYSICAL_MASK Kirill A. Shutemov
2022-02-24 15:56 ` [PATCHv4 07/30] x86/traps: Add #VE support for TDX guest Kirill A. Shutemov
2022-02-24 18:36   ` Dave Hansen
2022-02-25 19:30     ` Kirill A. Shutemov
2022-02-25 19:46       ` Dave Hansen
2022-02-24 15:56 ` [PATCHv4 08/30] x86/tdx: Add HLT support for TDX guests Kirill A. Shutemov
2022-02-24 18:42   ` Dave Hansen
2022-02-24 15:56 ` [PATCHv4 09/30] x86/tdx: Add MSR " Kirill A. Shutemov
2022-02-24 18:52   ` Dave Hansen
2022-02-24 19:04     ` Sean Christopherson
2022-02-24 19:36       ` Dave Hansen
2022-02-26 21:35     ` Kirill A. Shutemov
2022-02-24 15:56 ` [PATCHv4 10/30] x86/tdx: Handle CPUID via #VE Kirill A. Shutemov
2022-02-24 19:04   ` Dave Hansen
2022-02-27  1:07     ` Kirill A. Shutemov
2022-02-28 16:41       ` Dave Hansen
2022-02-28 22:53         ` Kirill A. Shutemov
2022-02-28 23:05           ` Dave Hansen
2022-02-28 23:31             ` Kirill A. Shutemov
2022-02-28 23:37               ` Dave Hansen
2022-02-24 15:56 ` [PATCHv4 11/30] x86/tdx: Handle in-kernel MMIO Kirill A. Shutemov
2022-02-24 20:11   ` Dave Hansen
2022-02-25  2:23     ` David Laight
2022-02-25  3:10       ` David Laight
2022-03-02 13:42     ` Kirill A. Shutemov
2022-02-24 15:56 ` [PATCHv4 12/30] x86/tdx: Detect TDX at early kernel decompression time Kirill A. Shutemov
2022-02-24 20:44   ` Dave Hansen
2022-02-24 15:56 ` [PATCHv4 13/30] x86: Adjust types used in port I/O helpers Kirill A. Shutemov
2022-02-24 21:24   ` Dave Hansen
2022-02-24 15:56 ` [PATCHv4 14/30] x86: Consolidate " Kirill A. Shutemov
2022-02-24 15:56 ` [PATCHv4 15/30] x86/boot: Allow to hook up alternative " Kirill A. Shutemov
2022-02-24 22:14   ` Dave Hansen
2022-02-27 22:02   ` Josh Poimboeuf
2022-02-28 16:33     ` Kirill A. Shutemov
2022-02-28 16:44       ` Josh Poimboeuf
2022-02-24 15:56 ` [PATCHv4 16/30] x86/boot/compressed: Support TDX guest port I/O at decompression time Kirill A. Shutemov
2022-02-24 22:22   ` Dave Hansen
2022-02-24 15:56 ` [PATCHv4 17/30] x86/tdx: Add port I/O emulation Kirill A. Shutemov
2022-02-24 22:43   ` Dave Hansen [this message]
2022-02-25  3:59   ` Dave Hansen
2022-02-28  1:16     ` Kirill A. Shutemov
2022-02-28  4:32       ` Dave Hansen
2022-02-24 15:56 ` [PATCHv4 18/30] x86/tdx: Handle early boot port I/O Kirill A. Shutemov
2022-02-24 22:58   ` Dave Hansen
2022-02-24 15:56 ` [PATCHv4 19/30] x86/tdx: Wire up KVM hypercalls Kirill A. Shutemov
2022-02-24 15:56 ` [PATCHv4 20/30] x86/boot: Add a trampoline for booting APs via firmware handoff Kirill A. Shutemov
2022-02-24 15:56 ` [PATCHv4 21/30] x86/acpi, x86/boot: Add multiprocessor wake-up support Kirill A. Shutemov
2022-02-24 15:56 ` [PATCHv4 22/30] x86/boot: Set CR0.NE early and keep it set during the boot Kirill A. Shutemov
2022-02-24 15:56 ` [PATCHv4 23/30] x86/boot: Avoid #VE during boot for TDX platforms Kirill A. Shutemov
2022-02-24 15:56 ` [PATCHv4 24/30] x86/topology: Disable CPU online/offline control for TDX guests Kirill A. Shutemov
2022-02-24 15:56 ` [PATCHv4 25/30] x86/tdx: Make pages shared in ioremap() Kirill A. Shutemov
2022-02-24 15:56 ` [PATCHv4 26/30] x86/mm/cpa: Add support for TDX shared memory Kirill A. Shutemov
2022-02-24 15:56 ` [PATCHv4 27/30] x86/kvm: Use bounce buffers for TD guest Kirill A. Shutemov
2022-02-24 15:56 ` [PATCHv4 28/30] x86/tdx: ioapic: Add shared bit for IOAPIC base address Kirill A. Shutemov
2022-02-24 15:56 ` [PATCHv4 29/30] ACPICA: Avoid cache flush on TDX guest Kirill A. Shutemov
2022-02-27 22:05   ` Josh Poimboeuf
2022-02-28  1:34     ` Dan Williams
2022-02-28 16:37       ` Kirill A. Shutemov
2022-02-28 16:46         ` Dave Hansen
2022-02-28 17:02         ` Josh Poimboeuf
2022-02-24 15:56 ` [PATCHv4 30/30] Documentation/x86: Document TDX kernel architecture Kirill A. Shutemov
2022-02-25 17:42   ` Dave Hansen
2022-02-25 17:54   ` Dave Hansen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=554143b6-36c6-d192-9662-1a5ac6dfa97f@intel.com \
    --to=dave.hansen@intel.com \
    --cc=aarcange@redhat.com \
    --cc=ak@linux.intel.com \
    --cc=bp@alien8.de \
    --cc=brijesh.singh@amd.com \
    --cc=dan.j.williams@intel.com \
    --cc=david@redhat.com \
    --cc=hpa@zytor.com \
    --cc=jgross@suse.com \
    --cc=jmattson@google.com \
    --cc=joro@8bytes.org \
    --cc=jpoimboe@redhat.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=knsathya@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peterz@infradead.org \
    --cc=sathyanarayanan.kuppuswamy@linux.intel.com \
    --cc=sdeep@vmware.com \
    --cc=seanjc@google.com \
    --cc=tglx@linutronix.de \
    --cc=thomas.lendacky@amd.com \
    --cc=tony.luck@intel.com \
    --cc=vkuznets@redhat.com \
    --cc=wanpengli@tencent.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®