From patchwork Mon Jul 1 07:30:06 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Binbin Wu X-Patchwork-Id: 13717615 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.8]) (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 58B3A6F076 for ; Mon, 1 Jul 2024 07:28:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.8 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1719818935; cv=none; b=OShsGaDx0aqApac0fsdU/rVDK52x7S25qrL9ChUEzgxZ568MkkoZXmE01/G3cFsPnsnOTkMr8w8142LOP8PvsZ0bJ4uv6MrRl8gOch4fSYXM3c8l28WLG39TdKkzRydJOPawRK6EBwoGjukq1BBRQzfW+rO2K1UQZJLcifSxnwY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1719818935; c=relaxed/simple; bh=WLgmrTY4QdDY85toOWC+nVIBypmmx5gQ9PJOsEQ2IwM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=aGQaUpGaMHxN69z2DzPiTP+5rbWTlUm8IEOIAa/nF1b1lnKoYIzQ5B0haN+gkhpHk8IsMce6xe4aVOG7qzMbPjx0vg4niC/n3TrZYKWqX9BCOr0vKTNcobBxgPFKKqqsavuLQd4ZJeCmrxbniwBd1WOxM91MJN9FYG+CK+chxJI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=moDjIj4f; arc=none smtp.client-ip=192.198.163.8 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="moDjIj4f" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1719818935; x=1751354935; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=WLgmrTY4QdDY85toOWC+nVIBypmmx5gQ9PJOsEQ2IwM=; b=moDjIj4feLYSLUsX86oGY/C7gZlV6FWvlmIOU/kxNCfIBDXJBlPbU/uH 1Now2ouHbdm5ttoyK0x4UkuA/AHwArJ1uR7ZthNNU97Mkw6pgDYlCPcUb SSJasLoYg1fEVcLUHttvhm/L7tsFbW4ozfMN1djU2NYkjlCav/MVp/P+o WtvV/AYOzcW1U9akEX60J/Pg6vBYGzrk4+/WChOV3ry+dPFo/ESmOOvSb P6dTn5lX5Kgdgd9AwrqcN+nDwL8XnjywSBkFuWDnfrNJwJxaV6LPSStQD 3UfXFDYrwrx+GBf13gpOMUUdxzjH9GqUIxVQjVLhSSGUZg2mqk8Ig1kgB A==; X-CSE-ConnectionGUID: Sg52LsGQQXS0LIQJTIsKIw== X-CSE-MsgGUID: GmrN/WX2Tr29fJOcheD3Zg== X-IronPort-AV: E=McAfee;i="6700,10204,11119"; a="34466038" X-IronPort-AV: E=Sophos;i="6.09,175,1716274800"; d="scan'208";a="34466038" Received: from orviesa009.jf.intel.com ([10.64.159.149]) by fmvoesa102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Jul 2024 00:28:54 -0700 X-CSE-ConnectionGUID: pBp1oYPLRJSUDgWKkC7xQw== X-CSE-MsgGUID: jxjMQU5XQ+2zX6vv7OgKsA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.09,175,1716274800"; d="scan'208";a="45520746" Received: from unknown (HELO litbin-desktop.sh.intel.com) ([10.239.156.93]) by orviesa009-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Jul 2024 00:28:50 -0700 From: Binbin Wu To: kvm@vger.kernel.org Cc: seanjc@google.com, pbonzini@redhat.com, chao.gao@intel.com, robert.hu@linux.intel.com, robert.hoo.linux@gmail.com, binbin.wu@linux.intel.com Subject: [kvm-unit-tests PATCH v7 1/5] x86: Move struct invpcid_desc to processor.h Date: Mon, 1 Jul 2024 15:30:06 +0800 Message-ID: <20240701073010.91417-2-binbin.wu@linux.intel.com> X-Mailer: git-send-email 2.43.2 In-Reply-To: <20240701073010.91417-1-binbin.wu@linux.intel.com> References: <20240701073010.91417-1-binbin.wu@linux.intel.com> Precedence: bulk X-Mailing-List: kvm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Move struct invpcid_desc to processor.h so that new test cases need to do invpcid can use the definition. Opportunistically add packed attribute, because according to C standard, the allocation of storage unit for bit-field is implementation specific. Signed-off-by: Binbin Wu --- v7: - New added. --- lib/x86/processor.h | 6 ++++++ x86/pcid.c | 6 ------ 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/lib/x86/processor.h b/lib/x86/processor.h index da1ed662..85a1781b 100644 --- a/lib/x86/processor.h +++ b/lib/x86/processor.h @@ -959,4 +959,10 @@ static inline void generate_cr0_em_nm(void) fnop(); } +struct invpcid_desc { + u64 pcid : 12; + u64 rsv : 52; + u64 addr : 64; +} __attribute__((packed)); + #endif diff --git a/x86/pcid.c b/x86/pcid.c index c503efb8..7425e0fe 100644 --- a/x86/pcid.c +++ b/x86/pcid.c @@ -4,12 +4,6 @@ #include "processor.h" #include "desc.h" -struct invpcid_desc { - u64 pcid : 12; - u64 rsv : 52; - u64 addr : 64; -}; - static void test_pcid_enabled(void) { int passed = 0; From patchwork Mon Jul 1 07:30:07 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Binbin Wu X-Patchwork-Id: 13717616 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.8]) (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 AE00E76EEA for ; Mon, 1 Jul 2024 07:28:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.8 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1719818937; cv=none; b=knMorreUGhbTPcV3VGjvEbr7YecLMzgRrrvxh2zopo5/BRcZCAyGjj5FSCa+7zJyWmeYas567+roqjDnZlpBZl2k2VGpDWMunFUSFLmPCcF++awu6xPd1801fIPQOpMXCFly3p8WAlRHnaUg6yGyC9LJkiZoCl0hFPNVDJCnrP4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1719818937; c=relaxed/simple; bh=30JVOnpoaKDhlOtl8mzP0pku8g0yJvz3LLkq2KbgoaE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=YoUvx53L+DHw69lxNefzVkMY/yaP9ZzOyM5HE+XQmKfK04iyvd+2Ds0ogbBbl3pJozkCWHp8qoept9xBS55s1OQPK4s8kCA8WdL4uJ6pYsggnmk5xTrViFNojTuBOwN6A7FPTk41P/1RNJK8k39Mn8IqrLO4vZD9qRq27DiGfPQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=W30NN9i1; arc=none smtp.client-ip=192.198.163.8 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="W30NN9i1" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1719818936; x=1751354936; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=30JVOnpoaKDhlOtl8mzP0pku8g0yJvz3LLkq2KbgoaE=; b=W30NN9i1yyaYHoIOyldICHsIlgl7HJFe2iN4lxSFATC033+XWVE4N4lm iRfRtr27htEdtNFkwvzfjjFHfIsVSjOMefZy5+TNw9l0jJNqBM57CPUmP pNwWbJSSsJXhJxM4e4xPu37jY8nl3HRatsaXoqcxqVQi87aQfxfewNjxC wrdQXFEKPHsmMyLVucBqkfi9DeaaEUNtU+P4R/9LYFnFAP2gSrBaQ1Z1g yhs+ccuUQS8CDwfNmez1V/R0vKZiqKtqBMuqVHOFaRKzeqzB+EgJEi4Go 1NrjgjXlBJrMuAlq6Uc3XUtjOpdZI/JsEgqpPM+qI9MLgNozsyKFJ61ER w==; X-CSE-ConnectionGUID: +SDcg682SnqrFrEX52juHg== X-CSE-MsgGUID: 7+/kskTQR6yI6iKx5HGbyw== X-IronPort-AV: E=McAfee;i="6700,10204,11119"; a="34466052" X-IronPort-AV: E=Sophos;i="6.09,175,1716274800"; d="scan'208";a="34466052" Received: from orviesa009.jf.intel.com ([10.64.159.149]) by fmvoesa102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Jul 2024 00:28:56 -0700 X-CSE-ConnectionGUID: Bx1pa/dFQOq/tUJ7xsH2tg== X-CSE-MsgGUID: 5VKhoQzZQr+yaSpsQtnw4A== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.09,175,1716274800"; d="scan'208";a="45520753" Received: from unknown (HELO litbin-desktop.sh.intel.com) ([10.239.156.93]) by orviesa009-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Jul 2024 00:28:53 -0700 From: Binbin Wu To: kvm@vger.kernel.org Cc: seanjc@google.com, pbonzini@redhat.com, chao.gao@intel.com, robert.hu@linux.intel.com, robert.hoo.linux@gmail.com, binbin.wu@linux.intel.com Subject: [kvm-unit-tests PATCH v7 2/5] x86: Allow setting of CR3 LAM bits if LAM supported Date: Mon, 1 Jul 2024 15:30:07 +0800 Message-ID: <20240701073010.91417-3-binbin.wu@linux.intel.com> X-Mailer: git-send-email 2.43.2 In-Reply-To: <20240701073010.91417-1-binbin.wu@linux.intel.com> References: <20240701073010.91417-1-binbin.wu@linux.intel.com> Precedence: bulk X-Mailing-List: kvm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 If LINEAR ADDRESS MASKING (LAM) is supported, VM entry allows CR3.LAM_U48 (bit 62) and CR3.LAM_U57 (bit 61) to be set in CR3 field. Change the test result expectations when setting CR3.LAM_U48 or CR3.LAM_U57 on vmlaunch tests when LAM is supported. Signed-off-by: Binbin Wu Reviewed-by: Chao Gao --- lib/x86/processor.h | 3 +++ x86/vmx_tests.c | 6 +++++- 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/lib/x86/processor.h b/lib/x86/processor.h index 85a1781b..f7f2df50 100644 --- a/lib/x86/processor.h +++ b/lib/x86/processor.h @@ -68,6 +68,8 @@ #define X86_CR0_PG BIT(X86_CR0_PG_BIT) #define X86_CR3_PCID_MASK GENMASK(11, 0) +#define X86_CR3_LAM_U57_BIT (61) +#define X86_CR3_LAM_U48_BIT (62) #define X86_CR4_VME_BIT (0) #define X86_CR4_VME BIT(X86_CR4_VME_BIT) @@ -262,6 +264,7 @@ static inline bool is_intel(void) #define X86_FEATURE_FLUSH_L1D (CPUID(0x7, 0, EDX, 28)) #define X86_FEATURE_ARCH_CAPABILITIES (CPUID(0x7, 0, EDX, 29)) #define X86_FEATURE_PKS (CPUID(0x7, 0, ECX, 31)) +#define X86_FEATURE_LAM (CPUID(0x7, 1, EAX, 26)) /* * KVM defined leafs diff --git a/x86/vmx_tests.c b/x86/vmx_tests.c index ffe7064c..4b161c3c 100644 --- a/x86/vmx_tests.c +++ b/x86/vmx_tests.c @@ -7032,7 +7032,11 @@ static void test_host_ctl_regs(void) cr3 = cr3_saved | (1ul << i); vmcs_write(HOST_CR3, cr3); report_prefix_pushf("HOST_CR3 %lx", cr3); - test_vmx_vmlaunch(VMXERR_ENTRY_INVALID_HOST_STATE_FIELD); + if (this_cpu_has(X86_FEATURE_LAM) && + ((i == X86_CR3_LAM_U57_BIT) || (i == X86_CR3_LAM_U48_BIT))) + test_vmx_vmlaunch(0); + else + test_vmx_vmlaunch(VMXERR_ENTRY_INVALID_HOST_STATE_FIELD); report_prefix_pop(); } From patchwork Mon Jul 1 07:30:08 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Binbin Wu X-Patchwork-Id: 13717617 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.8]) (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 690106EB5B for ; Mon, 1 Jul 2024 07:28:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.8 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1719818941; cv=none; b=VCTQcvNRJnZ6jKA623spk/UR//fup8+nn3eeg2Dabh55Dsq2dYV1cVWXs9Nq56YaMZdthd0wijILhiiV/inZ9Pgb5g8pmBEnR5YzKSs+T7op77fdq0s742GZElZfjlScJ2skMfd29A1WT7si8UqL+jU7Pu0qywBariBiO3YjaqQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1719818941; c=relaxed/simple; bh=/GYMLo462TQO2m2jxgFKvSjjHSn0vItDPc/nCPHQFpc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=A6a/eTIGNrEflxc6imYy2TlU975EiUWxD3DO+wi7XV1X3sTidcxjV3/H8Py3JLGGrhBUvml0UdqrIK01g+nTJhyYokWi34acNnzUvK0pByInqCO4kYaUUDeua0lDzmdOIRBwETWl0tor/6ee1HjiuHPJj1eBf21K7IM9x+wUK9A= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=CN/ShCnc; arc=none smtp.client-ip=192.198.163.8 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="CN/ShCnc" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1719818940; x=1751354940; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=/GYMLo462TQO2m2jxgFKvSjjHSn0vItDPc/nCPHQFpc=; b=CN/ShCncGWkpMk2rJY55gxB4G7/WWU0GMzDurS+7yq9QCOz+RloQfBa5 7KW8vC9ojs22TwgVD3xRiHJYe4KRHhLit8K1CJr3vSjyOpc9jD5j/qf0w JwG04tbCDww2WGbjidpCXaBNSIg18fgINtL7426cWzAqhWYsuPJ74rPd1 /G5cATH7b6qgPW8SYV9udP6zsFQNZdPFWg2Q4cTZwJfTxKCryUAbIFGY5 eT/69Pzlf6DmOgiReNbq/SjMCmMkYXs4n9XIceCe7tMTHFsWigIz5mFdL R2DCwTXgkSmhWTcWX37DV+tIa5Yu3S1nk65L2hEAXetASTuf3QEpwEoMz A==; X-CSE-ConnectionGUID: AZeHStTRSnChtwEJSGuhkQ== X-CSE-MsgGUID: o7Per+jtS360ZQ2EMu8vHw== X-IronPort-AV: E=McAfee;i="6700,10204,11119"; a="34466071" X-IronPort-AV: E=Sophos;i="6.09,175,1716274800"; d="scan'208";a="34466071" Received: from orviesa009.jf.intel.com ([10.64.159.149]) by fmvoesa102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Jul 2024 00:28:59 -0700 X-CSE-ConnectionGUID: wEfRGhJlQPyzq9zgkW2Dfg== X-CSE-MsgGUID: ihpXgy1bSbWhJU1xL1auHg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.09,175,1716274800"; d="scan'208";a="45520765" Received: from unknown (HELO litbin-desktop.sh.intel.com) ([10.239.156.93]) by orviesa009-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Jul 2024 00:28:55 -0700 From: Binbin Wu To: kvm@vger.kernel.org Cc: seanjc@google.com, pbonzini@redhat.com, chao.gao@intel.com, robert.hu@linux.intel.com, robert.hoo.linux@gmail.com, binbin.wu@linux.intel.com Subject: [kvm-unit-tests PATCH v7 3/5] x86: Add test case for LAM_SUP Date: Mon, 1 Jul 2024 15:30:08 +0800 Message-ID: <20240701073010.91417-4-binbin.wu@linux.intel.com> X-Mailer: git-send-email 2.43.2 In-Reply-To: <20240701073010.91417-1-binbin.wu@linux.intel.com> References: <20240701073010.91417-1-binbin.wu@linux.intel.com> Precedence: bulk X-Mailing-List: kvm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Robert Hoo This unit test covers: 1. CR4.LAM_SUP toggles. 2. Memory & MMIO access with supervisor mode address with LAM metadata. 3. INVLPG memory operand doesn't contain LAM meta data, if the address is non-canonical form then the INVLPG is the same as a NOP (no #GP). 4. INVPCID memory operand (descriptor pointer) could contain LAM meta data, however, the address in the descriptor should be canonical. In x86/unittests.cfg, add 2 test cases/guest conf, with and without LAM. LAM feature spec: https://cdrdv2.intel.com/v1/dl/getContent/671368, Chapter LINEAR ADDRESS MASKING (LAM) Signed-off-by: Robert Hoo Co-developed-by: Binbin Wu Signed-off-by: Binbin Wu Reviewed-by: Chao Gao --- v7： - Rename is_la57()/lam_sup_active() to is_la57_enabled()/is_lam_sup_enabled(), and move them to processor.h (Sean) - Drop cr4_set_lam_sup()/cr4_clear_lam_sup() and use write_cr4_safe() instead. (Sean) - Add get_lam_mask() to get lam status based on the address and vCPU state. (Sean) - Drop the wrappers for INVLPG since INVLPG never faults. (Sean) - Drop the wrapper for INVPCID and use invpcid_safe() instead. (Sean) - Drop the check for X86_FEATURE_PCID. (Sean) --- lib/x86/processor.h | 20 +++++ x86/Makefile.x86_64 | 1 + x86/lam.c | 214 ++++++++++++++++++++++++++++++++++++++++++++ x86/unittests.cfg | 10 +++ 4 files changed, 245 insertions(+) create mode 100644 x86/lam.c diff --git a/lib/x86/processor.h b/lib/x86/processor.h index f7f2df50..a38f87ed 100644 --- a/lib/x86/processor.h +++ b/lib/x86/processor.h @@ -8,6 +8,14 @@ #include #define NONCANONICAL 0xaaaaaaaaaaaaaaaaull +#define LAM57_MASK GENMASK_ULL(62, 57) +#define LAM48_MASK GENMASK_ULL(62, 48) + +/* Set metadata with non-canonical pattern in mask bits of a linear address */ +static inline u64 set_la_non_canonical(u64 src, u64 mask) +{ + return (src & ~mask) | (NONCANONICAL & mask); +} #ifdef __x86_64__ # define R "r" @@ -120,6 +128,8 @@ #define X86_CR4_CET BIT(X86_CR4_CET_BIT) #define X86_CR4_PKS_BIT (24) #define X86_CR4_PKS BIT(X86_CR4_PKS_BIT) +#define X86_CR4_LAM_SUP_BIT (28) +#define X86_CR4_LAM_SUP BIT(X86_CR4_LAM_SUP_BIT) #define X86_EFLAGS_CF_BIT (0) #define X86_EFLAGS_CF BIT(X86_EFLAGS_CF_BIT) @@ -968,4 +978,14 @@ struct invpcid_desc { u64 addr : 64; } __attribute__((packed)); +static inline bool is_la57_enabled(void) +{ + return !!(read_cr4() & X86_CR4_LA57); +} + +static inline bool is_lam_sup_enabled(void) +{ + return !!(read_cr4() & X86_CR4_LAM_SUP); +} + #endif diff --git a/x86/Makefile.x86_64 b/x86/Makefile.x86_64 index 2771a6fa..e5db2365 100644 --- a/x86/Makefile.x86_64 +++ b/x86/Makefile.x86_64 @@ -38,6 +38,7 @@ tests += $(TEST_DIR)/rdpru.$(exe) tests += $(TEST_DIR)/pks.$(exe) tests += $(TEST_DIR)/pmu_lbr.$(exe) tests += $(TEST_DIR)/pmu_pebs.$(exe) +tests += $(TEST_DIR)/lam.$(exe) ifeq ($(CONFIG_EFI),y) tests += $(TEST_DIR)/amd_sev.$(exe) diff --git a/x86/lam.c b/x86/lam.c new file mode 100644 index 00000000..2f95b6c9 --- /dev/null +++ b/x86/lam.c @@ -0,0 +1,214 @@ +/* + * Intel LAM unit test + * + * Copyright (C) 2023 Intel + * + * Author: Robert Hoo + * Binbin Wu + * + * This work is licensed under the terms of the GNU LGPL, version 2 or + * later. + */ + +#include "libcflat.h" +#include "processor.h" +#include "desc.h" +#include "vmalloc.h" +#include "alloc_page.h" +#include "vm.h" +#include "asm/io.h" +#include "ioram.h" + +static void test_cr4_lam_set_clear(void) +{ + int vector; + bool has_lam = this_cpu_has(X86_FEATURE_LAM); + + vector = write_cr4_safe(read_cr4() | X86_CR4_LAM_SUP); + report(has_lam ? !vector : vector == GP_VECTOR, + "Expected CR4.LAM_SUP=1 to %s", has_lam ? "succeed" : "#GP"); + + vector = write_cr4_safe(read_cr4() & ~X86_CR4_LAM_SUP); + report(!vector, "Expected CR4.LAM_SUP=0 to succeed"); +} + +/* Refer to emulator.c */ +static void do_mov(void *mem) +{ + unsigned long t1, t2; + + t1 = 0x123456789abcdefull & -1ul; + asm volatile("mov %[t1], (%[mem])\n\t" + "mov (%[mem]), %[t2]" + : [t2]"=r"(t2) + : [t1]"r"(t1), [mem]"r"(mem) + : "memory"); + report(t1 == t2, "Mov result check"); +} + +static bool get_lam_mask(u64 address, u64* lam_mask) +{ + /* + * Use LAM57_MASK as mask to construct non-canonical address if LAM is + * not supported or enabled. + */ + *lam_mask = LAM57_MASK; + + /* + * Bit 63 determines if the address should be treated as a user address + * or a supervisor address. + */ + if (address & BIT_ULL(63)) { + if (!(is_lam_sup_enabled())) + return false; + + if (!is_la57_enabled()) + *lam_mask = LAM48_MASK; + return true; + } + + /* TODO: Get LAM mask for userspace address. */ + return false; +} + + +static void test_ptr(u64* ptr, bool is_mmio) +{ + u64 lam_mask; + bool lam_active, fault; + + lam_active = get_lam_mask((u64)ptr, &lam_mask); + + fault = test_for_exception(GP_VECTOR, do_mov, ptr); + report(!fault, "Expected access to untagged address for %s to succeed", + is_mmio ? "MMIO" : "memory"); + + ptr = (u64 *)set_la_non_canonical((u64)ptr, lam_mask); + fault = test_for_exception(GP_VECTOR, do_mov, ptr); + report(fault != lam_active, "Expected access to tagged address for %s %s LAM to %s", + is_mmio ? "MMIO" : "memory", lam_active ? "with" : "without", + lam_active ? "succeed" : "#GP"); +} + +/* invlpg with tagged address is same as NOP, no #GP expected. */ +static void test_invlpg(void *va, bool fep) +{ + u64 lam_mask; + u64 *ptr; + + /* + * The return value is not checked, invlpg should never faults no matter + * LAM is supported or not. + */ + get_lam_mask((u64)va, &lam_mask); + ptr = (u64 *)set_la_non_canonical((u64)va, lam_mask); + if (fep) + asm volatile(KVM_FEP "invlpg (%0)" ::"r" (ptr) : "memory"); + else + invlpg(ptr); + + report(true, "Expected %sINVLPG with tagged addr to succeed", fep ? "fep: " : ""); +} + +/* LAM doesn't apply to the linear address in the descriptor of invpcid */ +static void test_invpcid(void *data) +{ + /* + * Reuse the memory address for the descriptor since stack memory + * address in KUT doesn't follow the kernel address space partitions. + */ + struct invpcid_desc *desc_ptr = (struct invpcid_desc *)data; + int vector; + u64 lam_mask; + bool lam_active; + + if (!this_cpu_has(X86_FEATURE_INVPCID)) { + report_skip("INVPCID not supported"); + return; + } + + lam_active = get_lam_mask((u64)data, &lam_mask); + + memset(desc_ptr, 0, sizeof(struct invpcid_desc)); + desc_ptr->addr = (u64)data; + + vector = invpcid_safe(0, desc_ptr); + report(!vector, + "Expected INVPCID with untagged pointer + untagged addr to succeed"); + + desc_ptr->addr = set_la_non_canonical(desc_ptr->addr, lam_mask); + vector = invpcid_safe(0, desc_ptr); + report(vector==GP_VECTOR, + "Expected INVPCID with untagged pointer + tagged addr to #GP"); + + desc_ptr = (struct invpcid_desc *)set_la_non_canonical((u64)desc_ptr, + lam_mask); + vector = invpcid_safe(0, desc_ptr); + report(vector==GP_VECTOR, + "Expected INVPCID with tagged pointer + tagged addr to #GP"); + + desc_ptr = (struct invpcid_desc *)data; + desc_ptr->addr = (u64)data; + desc_ptr = (struct invpcid_desc *)set_la_non_canonical((u64)desc_ptr, + lam_mask); + vector = invpcid_safe(0, desc_ptr); + report(lam_active ? !vector : vector==GP_VECTOR, + "Expected INVPCID with tagged pointer + untagged addr to %s", + lam_active? "succeed" : "#GP"); +} + +static void test_lam_sup(void) +{ + void *vaddr, *vaddr_mmio; + phys_addr_t paddr; + unsigned long cr4 = read_cr4(); + int vector; + + /* + * KUT initializes vfree_top to 0 for X86_64, and each virtual address + * allocation decreases the size from vfree_top. It's guaranteed that + * the return value of alloc_vpage() is considered as kernel mode + * address and canonical since only a small mount virtual address range + * is allocated in this test. + */ + vaddr = alloc_vpage(); + vaddr_mmio = alloc_vpage(); + paddr = virt_to_phys(alloc_page()); + install_page(current_page_table(), paddr, vaddr); + install_page(current_page_table(), IORAM_BASE_PHYS, vaddr_mmio); + + test_cr4_lam_set_clear(); + + /* Set for the following LAM_SUP tests. */ + if (this_cpu_has(X86_FEATURE_LAM)) { + vector = write_cr4_safe(cr4 | X86_CR4_LAM_SUP); + report(!vector && is_lam_sup_enabled(), + "Expected CR4.LAM_SUP=1 to succeed"); + } + + /* Test for normal memory. */ + test_ptr(vaddr, false); + /* Test for MMIO to trigger instruction emulation. */ + test_ptr(vaddr_mmio, true); + test_invpcid(vaddr); + test_invlpg(vaddr, false); + if (is_fep_available()) + test_invlpg(vaddr, true); + else + report_skip("Skipping tests the forced emulation, " + "use kvm.force_emulation_prefix=1 to enable\n"); +} + +int main(int ac, char **av) +{ + setup_vm(); + + if (!this_cpu_has(X86_FEATURE_LAM)) + report_info("This CPU doesn't support LAM feature\n"); + else + report_info("This CPU supports LAM feature\n"); + + test_lam_sup(); + + return report_summary(); +} diff --git a/x86/unittests.cfg b/x86/unittests.cfg index 7c1691a9..f1178edd 100644 --- a/x86/unittests.cfg +++ b/x86/unittests.cfg @@ -490,3 +490,13 @@ file = cet.flat arch = x86_64 smp = 2 extra_params = -enable-kvm -m 2048 -cpu host + +[intel-lam] +file = lam.flat +arch = x86_64 +extra_params = -enable-kvm -cpu host + +[intel-no-lam] +file = lam.flat +arch = x86_64 +extra_params = -enable-kvm -cpu host,-lam From patchwork Mon Jul 1 07:30:09 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Binbin Wu X-Patchwork-Id: 13717618 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.8]) (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 5F31C6F073 for ; Mon, 1 Jul 2024 07:29:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.8 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1719818942; cv=none; b=TG0uaGEBKDioPEHcNj5M5Tpuyyw40W0qMswrVvwL65YIrK9JiXEwjckh/l5jCwYTQ9ETvjkHjLQaK5rN2cfrQfIklya9NlRNaSouLd1k9vILpID5/7GvX/vgacTTz1AgX9+69hmVuZEfv+54v4NZba0nbQdY387gwDMMei0fc+0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1719818942; c=relaxed/simple; bh=e7+jxry2SFnYtXrd/k0cTyP9s5BohouD1YnmQGsProc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=r1F87tD3+WKPONnJXLRGZxFprU9eb/b49qyGn/ukGerz1iCC9fRoF4HIXBvjlcerVLR2JG/xQYcOVl+wZRZtZZkM7I/A4TB+q/+2oIhnIw3dJtVmWLKKUd6/H0dygDy+HVkPT/RoL7GHz47HaWX/a+xpJcxlMbyqNRwd+l7d768= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=LFGkAIjw; arc=none smtp.client-ip=192.198.163.8 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="LFGkAIjw" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1719818942; x=1751354942; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=e7+jxry2SFnYtXrd/k0cTyP9s5BohouD1YnmQGsProc=; b=LFGkAIjwLcu0IwOnYPVZpiaCYKzbDqmXXMvpBPUNDRD8ONTa/yXEgzx6 JiUn2byN6gA4ARAT068sa3A7bMSSVdtGu89KeboanI76YsbX+Amoj/vfv bQwdUH3OgDQo55nfDUH+eRgba3Y6NhKmhFHRbKBEbhylZAkm7yfmz+4NI bSUhk6QKLecG/XqnDFjUwgZAhvC1m0zfo+5InnbjM3WoqMdUU41d5I1pg pnYt+3Ug7CjTS/F/dKpSjSUifOGTX4QSn171+NCbozPe0UUsnFtlMSFAL 5uL4ZgZsOjL1g1y4F5dys9PcjdlPBXrJKtjTW3iwHBoGVjmiIIPHsUKk5 g==; X-CSE-ConnectionGUID: zshVzyjYSoSNdLAdVjHjJg== X-CSE-MsgGUID: rIV8fUAsRvKBV/YWOk4Inw== X-IronPort-AV: E=McAfee;i="6700,10204,11119"; a="34466080" X-IronPort-AV: E=Sophos;i="6.09,175,1716274800"; d="scan'208";a="34466080" Received: from orviesa009.jf.intel.com ([10.64.159.149]) by fmvoesa102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Jul 2024 00:29:01 -0700 X-CSE-ConnectionGUID: vUPTGsNVRLOz1yn9/Gb3gw== X-CSE-MsgGUID: yEqYRQJ5QmmSHYcVVXqT0w== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.09,175,1716274800"; d="scan'208";a="45520778" Received: from unknown (HELO litbin-desktop.sh.intel.com) ([10.239.156.93]) by orviesa009-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Jul 2024 00:28:58 -0700 From: Binbin Wu To: kvm@vger.kernel.org Cc: seanjc@google.com, pbonzini@redhat.com, chao.gao@intel.com, robert.hu@linux.intel.com, robert.hoo.linux@gmail.com, binbin.wu@linux.intel.com Subject: [kvm-unit-tests PATCH v7 4/5] x86: Add test cases for LAM_{U48,U57} Date: Mon, 1 Jul 2024 15:30:09 +0800 Message-ID: <20240701073010.91417-5-binbin.wu@linux.intel.com> X-Mailer: git-send-email 2.43.2 In-Reply-To: <20240701073010.91417-1-binbin.wu@linux.intel.com> References: <20240701073010.91417-1-binbin.wu@linux.intel.com> Precedence: bulk X-Mailing-List: kvm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 This unit test covers: 1. CR3 LAM bits toggles. 2. Memory/MMIO access with user mode address containing LAM metadata. Signed-off-by: Binbin Wu Reviewed-by: Chao Gao --- v7: - Rename lam_{u48,u57}_active() to is_lam_{u48,u57}_enabled(), and move them to processor.h (Sean) - Get lam status based on the address and vCPU state. (Sean) - Test LAM userspace address in kernel mode directly to simplify the interface of test_ptr() since LAM identifies a address as kernel or user only based on the address itself. - Add comments about the virtualization hole of CR3 LAM bits. --- lib/x86/processor.h | 12 ++++++++ x86/lam.c | 69 ++++++++++++++++++++++++++++++++++++++++++++- 2 files changed, 80 insertions(+), 1 deletion(-) diff --git a/lib/x86/processor.h b/lib/x86/processor.h index a38f87ed..c2cafb01 100644 --- a/lib/x86/processor.h +++ b/lib/x86/processor.h @@ -77,7 +77,9 @@ static inline u64 set_la_non_canonical(u64 src, u64 mask) #define X86_CR3_PCID_MASK GENMASK(11, 0) #define X86_CR3_LAM_U57_BIT (61) +#define X86_CR3_LAM_U57 BIT_ULL(X86_CR3_LAM_U57_BIT) #define X86_CR3_LAM_U48_BIT (62) +#define X86_CR3_LAM_U48 BIT_ULL(X86_CR3_LAM_U48_BIT) #define X86_CR4_VME_BIT (0) #define X86_CR4_VME BIT(X86_CR4_VME_BIT) @@ -988,4 +990,14 @@ static inline bool is_lam_sup_enabled(void) return !!(read_cr4() & X86_CR4_LAM_SUP); } +static inline bool is_lam_u48_enabled(void) +{ + return (read_cr3() & (X86_CR3_LAM_U48 | X86_CR3_LAM_U57)) == X86_CR3_LAM_U48; +} + +static inline bool is_lam_u57_enabled(void) +{ + return !!(read_cr3() & X86_CR3_LAM_U57); +} + #endif diff --git a/x86/lam.c b/x86/lam.c index 2f95b6c9..40b8ecdd 100644 --- a/x86/lam.c +++ b/x86/lam.c @@ -67,7 +67,14 @@ static bool get_lam_mask(u64 address, u64* lam_mask) return true; } - /* TODO: Get LAM mask for userspace address. */ + if(is_lam_u48_enabled()) { + *lam_mask = LAM48_MASK; + return true; + } + + if(is_lam_u57_enabled()) + return true; + return false; } @@ -88,6 +95,17 @@ static void test_ptr(u64* ptr, bool is_mmio) report(fault != lam_active, "Expected access to tagged address for %s %s LAM to %s", is_mmio ? "MMIO" : "memory", lam_active ? "with" : "without", lam_active ? "succeed" : "#GP"); + + /* + * This test case is only triggered when LAM_U57 is active and 4-level + * paging is used. For the case, bit[56:47] aren't all 0 triggers #GP. + */ + if (lam_active && (lam_mask == LAM57_MASK) && !is_la57_enabled()) { + ptr = (u64 *)set_la_non_canonical((u64)ptr, LAM48_MASK); + fault = test_for_exception(GP_VECTOR, do_mov, ptr); + report(fault, "Expected access to non-LAM-canonical address for %s to #GP", + is_mmio ? "MMIO" : "memory"); + } } /* invlpg with tagged address is same as NOP, no #GP expected. */ @@ -199,6 +217,54 @@ static void test_lam_sup(void) "use kvm.force_emulation_prefix=1 to enable\n"); } +static void test_lam_user(void) +{ + void* vaddr; + int vector; + unsigned long cr3 = read_cr3() & ~(X86_CR3_LAM_U48 | X86_CR3_LAM_U57); + bool has_lam = this_cpu_has(X86_FEATURE_LAM); + + /* + * The physical address of AREA_NORMAL is within 36 bits, so that using + * identical mapping, the linear address will be considered as user mode + * address from the view of LAM, and the metadata bits are not used as + * address for both LAM48 and LAM57. + */ + vaddr = alloc_pages_flags(0, AREA_NORMAL); + _Static_assert((AREA_NORMAL_PFN & GENMASK(63, 47)) == 0UL, + "Identical mapping range check"); + + /* + * Note, LAM doesn't have a global control bit to turn on/off LAM + * completely, but purely depends on hardware's CPUID to determine it + * can be enabled or not. That means, when EPT is on, even when KVM + * doesn't expose LAM to guest, the guest can still set LAM control bits + * in CR3 w/o causing problem. This is an unfortunate virtualization + * hole. KVM doesn't choose to intercept CR3 in this case for + * performance. + * Only enable LAM CR3 bits when LAM feature is exposed. + */ + if (has_lam) { + vector = write_cr3_safe(cr3 | X86_CR3_LAM_U48); + report(!vector && is_lam_u48_enabled(), "Expected CR3.LAM_U48=1 to succeed"); + } + /* + * Physical memory & MMIO have already been identical mapped in + * setup_mmu(). + */ + test_ptr(vaddr, false); + test_ptr(phys_to_virt(IORAM_BASE_PHYS), true); + + if (has_lam) { + vector = write_cr3_safe(cr3 | X86_CR3_LAM_U57); + report(!vector && is_lam_u57_enabled(), "Expected CR3.LAM_U57=1 to succeed"); + + /* If !has_lam, it has been tested above, no need to test again. */ + test_ptr(vaddr, false); + test_ptr(phys_to_virt(IORAM_BASE_PHYS), true); + } +} + int main(int ac, char **av) { setup_vm(); @@ -209,6 +275,7 @@ int main(int ac, char **av) report_info("This CPU supports LAM feature\n"); test_lam_sup(); + test_lam_user(); return report_summary(); } From patchwork Mon Jul 1 07:30:10 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Binbin Wu X-Patchwork-Id: 13717619 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.8]) (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 0458376034 for ; Mon, 1 Jul 2024 07:29:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.8 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1719818945; cv=none; b=B6/XlM9fnikoLWh+JVyNZVsXh+AYXzUHil8FMPkCBmb7ihBQETVPKEVjiRuPW+GOdLd/6OpSuh4NBVBDgtvbC0Y9cfJ6CBosMRcjS+rkrzl0z4teCoNpG6lkynt8aomRdVMIjcwVYX+c2DTEz0qlazBbOlbRuBTir1uZ6xBeH24= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1719818945; c=relaxed/simple; bh=ESTTZBAxhyXhfSLIweAOqULss1TM2TroIHOc7KMqQBE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=FYhLyDaHAXBT1JV6hJZFgXQfGmRj+T0bxZWvRsYp2dVjY+63EuDtKaW3vVH2Jr4kbeTwiDnGCg3EspJRIZSl1fCid/LIz8Z3zZo14OaQAKA2kFNVXFPaTekbdv1BLGWcYgWCs+v46MnQ0cJ6yV93kku70B3c/THSMyrdsdIgbdk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=FolxFVp7; arc=none smtp.client-ip=192.198.163.8 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="FolxFVp7" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1719818944; x=1751354944; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=ESTTZBAxhyXhfSLIweAOqULss1TM2TroIHOc7KMqQBE=; b=FolxFVp7tEVhq30lh5mz3mrzggJ1ryGIb6DfCaASpCWnSgS5nfCAche2 p2RYsfCYaomDurkMaxXsJA3yjqPj3U0vpRzntRPCSJwXrXXYzAAUfpTid 5GA5eYhxexlKbSiU67uJZ/hxLha2WdBbVdGQQiwEaMnn9YOrVVUuFJw6+ pLHViO3OO9i69nXSXlTpwfFy21DirqVzJQmEKmwIFa808wxZUrZq3C4Lb c0l3imvIZFriu5YEDwTnrZQIT2wUOSvqUc680zGRQjVDh/DdzWrGIcf0P Ea4IZDY2vC4y9MnTNG6FyOXUJYcZdUKvlkwzqLsP7Ld7vlzQskNL/4qfm A==; X-CSE-ConnectionGUID: LttvT3nJQE+eVI1lTC5W2g== X-CSE-MsgGUID: 0OheEH19R56xcC85IMATSg== X-IronPort-AV: E=McAfee;i="6700,10204,11119"; a="34466087" X-IronPort-AV: E=Sophos;i="6.09,175,1716274800"; d="scan'208";a="34466087" Received: from orviesa009.jf.intel.com ([10.64.159.149]) by fmvoesa102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Jul 2024 00:29:03 -0700 X-CSE-ConnectionGUID: qzOWPE9qQP+7GdVhgj3FSw== X-CSE-MsgGUID: dqWqJi6DRBGfq9CnGMtz7Q== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.09,175,1716274800"; d="scan'208";a="45520785" Received: from unknown (HELO litbin-desktop.sh.intel.com) ([10.239.156.93]) by orviesa009-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Jul 2024 00:29:00 -0700 From: Binbin Wu To: kvm@vger.kernel.org Cc: seanjc@google.com, pbonzini@redhat.com, chao.gao@intel.com, robert.hu@linux.intel.com, robert.hoo.linux@gmail.com, binbin.wu@linux.intel.com Subject: [kvm-unit-tests PATCH v7 5/5] x86: Add test case for INVVPID with LAM Date: Mon, 1 Jul 2024 15:30:10 +0800 Message-ID: <20240701073010.91417-6-binbin.wu@linux.intel.com> X-Mailer: git-send-email 2.43.2 In-Reply-To: <20240701073010.91417-1-binbin.wu@linux.intel.com> References: <20240701073010.91417-1-binbin.wu@linux.intel.com> Precedence: bulk X-Mailing-List: kvm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 LAM applies to the linear address of INVVPID operand, however, it doesn't apply to the linear address in the INVVPID descriptor. The added cases use tagged operand or tagged target invalidation address to make sure the behaviors are expected when LAM is on. Also, INVVPID case using tagged operand can be used as the common test cases for VMX instruction VMExits. Signed-off-by: Binbin Wu Reviewed-by: Chao Gao --- v7: - Drop the check of X86_FEATURE_LA57 when check LA57. (Sean) --- x86/vmx_tests.c | 45 ++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 44 insertions(+), 1 deletion(-) diff --git a/x86/vmx_tests.c b/x86/vmx_tests.c index 4b161c3c..758ab0d3 100644 --- a/x86/vmx_tests.c +++ b/x86/vmx_tests.c @@ -3233,6 +3233,47 @@ static void invvpid_test_not_in_vmx_operation(void) TEST_ASSERT(!vmx_on()); } +/* LAM doesn't apply to the linear address inside the descriptor of invvpid */ +static void invvpid_test_lam(void) +{ + void *vaddr; + struct invvpid_operand *operand; + u64 lam_mask; + bool fault; + + if (!this_cpu_has(X86_FEATURE_LAM)) { + report_skip("LAM is not supported, skip INVVPID with LAM"); + return; + } + + write_cr4(read_cr4() | X86_CR4_LAM_SUP); + lam_mask = is_la57_enabled() ? LAM57_MASK : LAM48_MASK; + + vaddr = alloc_vpage(); + install_page(current_page_table(), virt_to_phys(alloc_page()), vaddr); + /* + * Since the stack memory address in KUT doesn't follow kernel address + * space partition rule, reuse the memory address for descriptor and + * the target address in the descriptor of invvpid. + */ + operand = (struct invvpid_operand *)vaddr; + operand->vpid = 0xffff; + operand->gla = (u64)vaddr; + operand = (struct invvpid_operand *)set_la_non_canonical((u64)operand, + lam_mask); + fault = test_for_exception(GP_VECTOR, ds_invvpid, operand); + report(!fault, "Expected INVVPID with tagged operand when LAM is enabled to succeed"); + + /* + * Verify that LAM doesn't apply to the address inside the descriptor + * even when LAM is enabled. i.e., the address in the descriptor should + * be canonical. + */ + try_invvpid(INVVPID_ADDR, 0xffff, (u64)operand); + + write_cr4(read_cr4() & ~X86_CR4_LAM_SUP); +} + /* * This does not test real-address mode, virtual-8086 mode, protected mode, * or CPL > 0. @@ -3282,8 +3323,10 @@ static void invvpid_test(void) /* * The gla operand is only validated for single-address INVVPID. */ - if (types & (1u << INVVPID_ADDR)) + if (types & (1u << INVVPID_ADDR)) { try_invvpid(INVVPID_ADDR, 0xffff, NONCANONICAL); + invvpid_test_lam(); + } invvpid_test_gp(); invvpid_test_ss();