From: Chao Gao <chao.gao@intel.com>
To: Binbin Wu <binbin.wu@linux.intel.com>
Cc: <kvm@vger.kernel.org>, <seanjc@google.com>, <pbonzini@redhat.com>,
<kai.huang@intel.com>, <xuelian.guo@intel.com>,
<robert.hu@linux.intel.com>
Subject: Re: [PATCH v7 3/5] KVM: x86: Introduce untag_addr() in kvm_x86_ops
Date: Fri, 21 Apr 2023 16:21:33 +0800 [thread overview]
Message-ID: <ZEJHjdc1d92h7ZdC@chao-email> (raw)
In-Reply-To: <22bd3eb6-a3a1-be75-925b-6f50b210a30f@linux.intel.com>
On Fri, Apr 21, 2023 at 03:48:50PM +0800, Binbin Wu wrote:
>
>On 4/19/2023 11:08 AM, Binbin Wu wrote:
>>
>> On 4/19/2023 10:30 AM, Chao Gao wrote:
>> > On Tue, Apr 04, 2023 at 09:09:21PM +0800, 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.
>> > The "flags" can be dropped. Callers can simply skip the call of
>> > .untag_addr().
>>
>> OK.
>>
>> The "flags" was added for proof of future if such kind of untag is also
>> adopted in svm for AMD.
>>
>> The cases to skip untag are different on the two vendor platforms.
>>
>> But still, it is able to get the information in __linearize(), I will
>> drop the parameter.
>
>Have a second thought, the flags is still needed to pass to vmx/svm.
>
>If both implementions set the skip untag flag (SKIP_UNTAG_VMX |
>SKIP_UNTAG_SVM)
>or neither sets the skip untag flag, __linearize() can decide to call
>.untag_addr() or not.
>
>However, in some case, if only one of the implementation need to set the skip
>untag for itself,
>in __linearize(), there is no enough information to tell whether to skip the
>untag or not.
OK. I have no strong preference. An alternative is:
We have only one flag. If AMD and Intel differ in some cases, set the
flag according to the CPU vendor of vCPUs.
if LAM applies to case A while AMD UAI doesn't, do
if guest CPU is Intel
set SKIP_UNTAG
for case B to which UAI applies while LAM doens't, do
if guest CPU is AMD
set SKIP_UNTAG
next prev parent reply other threads:[~2023-04-21 8:22 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
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 [this message]
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=ZEJHjdc1d92h7ZdC@chao-email \
--to=chao.gao@intel.com \
--cc=binbin.wu@linux.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 \
--cc=xuelian.guo@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox