From: Binbin Wu <binbin.wu@linux.intel.com>
To: Zeng Guang <guang.zeng@intel.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>, "Christopherson,,
Sean" <seanjc@google.com>,
"pbonzini@redhat.com" <pbonzini@redhat.com>
Cc: "Huang, Kai" <kai.huang@intel.com>,
"Gao, Chao" <chao.gao@intel.com>,
"Guo, Xuelian" <Xuelian.Guo@intel.com>,
"robert.hu@linux.intel.com" <robert.hu@linux.intel.com>
Subject: Re: [PATCH v7 3/5] KVM: x86: Introduce untag_addr() in kvm_x86_ops
Date: Tue, 18 Apr 2023 11:34:45 +0800 [thread overview]
Message-ID: <fa8ccc1a-b85f-8dee-ec22-9003152ea995@linux.intel.com> (raw)
In-Reply-To: <d0e57964-0c93-d5da-c95f-bbb33a010961@intel.com>
On 4/18/2023 11:08 AM, Zeng Guang wrote:
>
> On 4/4/2023 9:09 PM, Binbin Wu wrote:
>> Introduce a new interface untag_addr() to kvm_x86_ops to untag the
>> metadata
>> from linear address. Implement LAM version in VMX and dummy version
>> in SVM.
>>
>> When enabled feature like Intel Linear Address Masking or AMD Upper
>> Address Ignore, linear address may be tagged with metadata. Linear
>> address should be checked for modified canonicality and untagged in
>> instrution emulations or vmexit handlings if LAM or UAI is applicable.
>>
>> Introduce untag_addr() to kvm_x86_ops to hide the code related to vendor
>> specific details.
>> - For VMX, LAM version is implemented.
>> LAM has a modified canonical check when applicable:
>> * LAM_S48 : [ 1 ][ metadata ][ 1 ]
>> 63 47
>> * LAM_U48 : [ 0 ][ metadata ][ 0 ]
>> 63 47
>> * LAM_S57 : [ 1 ][ metadata ][ 1 ]
>> 63 56
>> * LAM_U57 + 5-lvl paging : [ 0 ][ metadata ][ 0 ]
>> 63 56
>> * LAM_U57 + 4-lvl paging : [ 0 ][ metadata ][ 0...0 ]
>> 63 56..47
>> If LAM is applicable to certain address, untag the metadata bits and
>> replace them with the value of bit 47 (LAM48) or bit 56 (LAM57).
>> Later
>> the untagged address will do legacy canonical check. So that LAM
>> canonical
>> check and mask can be covered by "untag + legacy canonical check".
>>
>> For cases LAM is not applicable, 'flags' is passed to the interface
>> to skip untag.
>>
>> - For SVM, add a dummy version to do nothing, but return the original
>> address.
>>
>> Signed-off-by: Binbin Wu <binbin.wu@linux.intel.com>
>> Tested-by: Xuelian Guo <xuelian.guo@intel.com>
>> ---
>> arch/x86/include/asm/kvm-x86-ops.h | 1 +
>> arch/x86/include/asm/kvm_host.h | 5 +++
>> arch/x86/kvm/svm/svm.c | 7 ++++
>> arch/x86/kvm/vmx/vmx.c | 60 ++++++++++++++++++++++++++++++
>> arch/x86/kvm/vmx/vmx.h | 2 +
>> 5 files changed, 75 insertions(+)
>>
>> diff --git a/arch/x86/include/asm/kvm-x86-ops.h
>> b/arch/x86/include/asm/kvm-x86-ops.h
>> index 8dc345cc6318..7d63d1b942ac 100644
>> --- a/arch/x86/include/asm/kvm-x86-ops.h
>> +++ b/arch/x86/include/asm/kvm-x86-ops.h
>> @@ -52,6 +52,7 @@ KVM_X86_OP(cache_reg)
>> KVM_X86_OP(get_rflags)
>> KVM_X86_OP(set_rflags)
>> KVM_X86_OP(get_if_flag)
>> +KVM_X86_OP(untag_addr)
>> KVM_X86_OP(flush_tlb_all)
>> KVM_X86_OP(flush_tlb_current)
>> KVM_X86_OP_OPTIONAL(tlb_remote_flush)
>> diff --git a/arch/x86/include/asm/kvm_host.h
>> b/arch/x86/include/asm/kvm_host.h
>> index 498d2b5e8dc1..cb674ec826d4 100644
>> --- a/arch/x86/include/asm/kvm_host.h
>> +++ b/arch/x86/include/asm/kvm_host.h
>> @@ -69,6 +69,9 @@
>> #define KVM_X86_NOTIFY_VMEXIT_VALID_BITS
>> (KVM_X86_NOTIFY_VMEXIT_ENABLED | \
>> KVM_X86_NOTIFY_VMEXIT_USER)
>> +/* flags for kvm_x86_ops::untag_addr() */
>> +#define KVM_X86_UNTAG_ADDR_SKIP_LAM _BITULL(0)
>> +
>
> Prefer to make definition and comments to be generic.
> How about:
> /* x86-specific emulation flags */
> #define KVM_X86_EMULFLAG_SKIP_LAM_UNTAG_ADDR _BITULL(0)
You mean make the flag definitions not dedicated for LAM, but also can
be used for other features?
AFAIK, LASS may also need to define similar flags for instruction
emulation and VMExit handling.
For me, I'd like to define it as:
/* x86-specific emulation flags */
#define KVM_X86_EMULFLAG_SKIP_LAM _BITULL(0)
since IMO, SKIP_LAM has described the purpose clearly already.
next prev parent reply other threads:[~2023-04-18 3:36 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-04 13:09 [PATCH v7 0/5] Linear Address Masking (LAM) KVM Enabling Binbin Wu
2023-04-04 13:09 ` [PATCH v7 1/5] KVM: x86: Virtualize CR4.LAM_SUP Binbin Wu
2023-04-04 13:09 ` [PATCH v7 2/5] KVM: x86: Virtualize CR3.LAM_{U48,U57} Binbin Wu
2023-04-06 12:57 ` Huang, Kai
2023-04-09 11:36 ` Binbin Wu
2023-04-11 23:11 ` Huang, Kai
2023-04-12 11:58 ` Huang, Kai
2023-04-13 1:36 ` Binbin Wu
2023-04-13 2:27 ` Huang, Kai
2023-04-13 4:45 ` Binbin Wu
2023-04-13 9:13 ` Huang, Kai
2023-04-21 6:35 ` Binbin Wu
2023-04-21 11:43 ` Huang, Kai
2023-04-21 15:32 ` Chao Gao
2023-04-22 4:51 ` Chao Gao
2023-04-22 8:14 ` Huang, Kai
2023-04-22 3:32 ` Binbin Wu
2023-04-22 4:43 ` Chao Gao
2023-04-27 13:19 ` Huang, Kai
2023-04-29 4:56 ` Binbin Wu
2023-04-25 22:48 ` Huang, Kai
2023-04-26 3:05 ` Chao Gao
2023-04-26 5:13 ` Binbin Wu
2023-04-26 8:44 ` Huang, Kai
2023-04-26 8:50 ` Binbin Wu
2023-04-26 8:43 ` Huang, Kai
2023-04-26 10:52 ` Binbin Wu
2023-04-27 13:23 ` Huang, Kai
2023-04-17 7:24 ` Chao Gao
2023-04-17 8:02 ` Binbin Wu
2023-04-04 13:09 ` [PATCH v7 3/5] KVM: x86: Introduce untag_addr() in kvm_x86_ops Binbin Wu
2023-04-18 3:08 ` Zeng Guang
2023-04-18 3:34 ` Binbin Wu [this message]
2023-04-19 2:30 ` Chao Gao
2023-04-19 3:08 ` Binbin Wu
2023-04-21 7:48 ` Binbin Wu
2023-04-21 8:21 ` Chao Gao
2023-04-04 13:09 ` [PATCH v7 4/5] KVM: x86: Untag address when LAM applicable Binbin Wu
2023-04-06 13:20 ` Huang, Kai
2023-04-10 3:35 ` Binbin Wu
2023-04-18 3:28 ` Zeng Guang
2023-04-18 3:38 ` Binbin Wu
2023-04-19 6:43 ` Chao Gao
2023-04-21 7:57 ` Binbin Wu
2023-04-21 8:36 ` Chao Gao
2023-04-21 9:13 ` Binbin Wu
2023-04-04 13:09 ` [PATCH v7 5/5] KVM: x86: Expose LAM feature to userspace VMM Binbin Wu
2023-04-21 9:40 ` [PATCH v7 0/5] Linear Address Masking (LAM) KVM Enabling Binbin Wu
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=fa8ccc1a-b85f-8dee-ec22-9003152ea995@linux.intel.com \
--to=binbin.wu@linux.intel.com \
--cc=Xuelian.Guo@intel.com \
--cc=chao.gao@intel.com \
--cc=guang.zeng@intel.com \
--cc=kai.huang@intel.com \
--cc=kvm@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=robert.hu@linux.intel.com \
--cc=seanjc@google.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.