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;
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From:   Andy Lutomirski <luto@amacapital.net>
Mime-Version: 1.0 (1.0)
Subject: Re: [PATCH v1 1/1] x86/tdx: Handle MWAIT, MONITOR and WBINVD
Date:   Fri, 26 Mar 2021 19:40:33 -0700
Message-Id: <89236DB3-7B03-4B11-9F5B-5D820289C544@amacapital.net>
References: <331b34e3d6153f0a7b0ab0a9a8cb5de71f0bfd93.1616803999.git.sathyanarayanan.kuppuswamy@linux.intel.com>
Cc:     Peter Zijlstra <peterz@infradead.org>,
        Andy Lutomirski <luto@kernel.org>,
        Dave Hansen <dave.hansen@intel.com>,
        Andi Kleen <ak@linux.intel.com>,
        Kirill Shutemov <kirill.shutemov@linux.intel.com>,
        Kuppuswamy Sathyanarayanan <knsathya@kernel.org>,
        Dan Williams <dan.j.williams@intel.com>,
        Raj Ashok <ashok.raj@intel.com>,
        Sean Christopherson <seanjc@google.com>,
        linux-kernel@vger.kernel.org
In-Reply-To: <331b34e3d6153f0a7b0ab0a9a8cb5de71f0bfd93.1616803999.git.sathyanarayanan.kuppuswamy@linux.intel.com>
To:     Kuppuswamy Sathyanarayanan 
        <sathyanarayanan.kuppuswamy@linux.intel.com>
Precedence: bulk


> On Mar 26, 2021, at 5:18 PM, Kuppuswamy Sathyanarayanan <sathyanarayanan.k=
uppuswamy@linux.intel.com> wrote:
>=20
> =EF=BB=BFIn non-root TDX guest mode, MWAIT, MONITOR and WBINVD instruction=
s
> are not supported. So handle #VE due to these instructions as no ops.

These should at least be WARN.

Does TDX send #UD if these instructions have the wrong CPL?  If the #VE came=
 from user mode, we should send an appropriate signal instead.

>=20
> Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linu=
x.intel.com>
> Reviewed-by: Andi Kleen <ak@linux.intel.com>
> ---
>=20
> Changes since previous series:
> * Suppressed MWAIT feature as per Andi's comment.
> * Added warning debug log for MWAIT #VE exception.
>=20
> arch/x86/kernel/tdx.c | 23 +++++++++++++++++++++++
> 1 file changed, 23 insertions(+)
>=20
> diff --git a/arch/x86/kernel/tdx.c b/arch/x86/kernel/tdx.c
> index e936b2f88bf6..fb7d22b846fc 100644
> --- a/arch/x86/kernel/tdx.c
> +++ b/arch/x86/kernel/tdx.c
> @@ -308,6 +308,9 @@ void __init tdx_early_init(void)
>=20
>    setup_force_cpu_cap(X86_FEATURE_TDX_GUEST);
>=20
> +    /* MWAIT is not supported in TDX platform, so suppress it */
> +    setup_clear_cpu_cap(X86_FEATURE_MWAIT);
> +
>    tdg_get_info();
>=20
>    pv_ops.irq.safe_halt =3D tdg_safe_halt;
> @@ -362,6 +365,26 @@ int tdg_handle_virtualization_exception(struct pt_reg=
s *regs,
>    case EXIT_REASON_EPT_VIOLATION:
>        ve->instr_len =3D tdg_handle_mmio(regs, ve);
>        break;
> +    /*
> +     * Per Guest-Host-Communication Interface (GHCI) for Intel Trust
> +     * Domain Extensions (Intel TDX) specification, sec 2.4,
> +     * some instructions that unconditionally cause #VE (such as WBINVD,
> +     * MONITOR, MWAIT) do not have corresponding TDCALL
> +     * [TDG.VP.VMCALL <Instruction>] leaves, since the TD has been design=
ed
> +     * with no deterministic way to confirm the result of those operation=
s
> +     * performed by the host VMM.  In those cases, the goal is for the TD=

> +     * #VE handler to increment the RIP appropriately based on the VE
> +     * information provided via TDCALL.
> +     */
> +    case EXIT_REASON_WBINVD:
> +        pr_warn_once("WBINVD #VE Exception\n");
> +    case EXIT_REASON_MONITOR_INSTRUCTION:
> +        /* Handle as nops. */
> +        break;
> +    case EXIT_REASON_MWAIT_INSTRUCTION:
> +        /* MWAIT is supressed, not supposed to reach here. */
> +        pr_warn("MWAIT unexpected #VE Exception\n");
> +        return -EFAULT;
>    default:
>        pr_warn("Unexpected #VE: %d\n", ve->exit_reason);
>        return -EFAULT;
> --=20
> 2.25.1
>=20