On 4/17/2021 1:30 AM, Sean Christopherson wrote:
On Fri, Apr 16, 2021, Kirill A. Shutemov wrote:
[...]
index fadaccb95a4c..cd2374802702 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -436,6 +436,8 @@ static inline int kvm_arch_vcpu_memslots_id(struct kvm_vcpu
*vcpu)
On 2/3/2021 12:05 AM, Paolo Bonzini wrote:
On 02/02/21 16:02, Xiaoyao Li wrote:
On 2/2/2021 10:49 PM, Paolo Bonzini wrote:
On 02/02/21 10:04, Chenyi Qiang wrote:
#define DR6_FIXED_1 0xfffe0ff0
-#define DR6_INIT 0x0ff0
+/*
+ * DR6_ACTIVE_LOW is actual the result of DR6_FIXED_1
On 3/27/2021 8:18 AM, Kuppuswamy Sathyanarayanan wrote:
In non-root TDX guest mode, MWAIT, MONITOR and WBINVD instructions
are not supported. So handle #VE due to these instructions as no ops.
Signed-off-by: Kuppuswamy Sathyanarayanan
Reviewed-by: Andi Kleen
---
Changes since previous
On 2/2/2021 10:49 PM, Paolo Bonzini wrote:
On 02/02/21 10:04, Chenyi Qiang wrote:
#define DR6_FIXED_1 0xfffe0ff0
-#define DR6_INIT 0x0ff0
+/*
+ * DR6_ACTIVE_LOW is actual the result of DR6_FIXED_1 | ACTIVE_LOW_BITS.
+ * We can regard all the current FIXED_1 bits as active_low bits
On 1/28/2021 3:25 PM, Paolo Bonzini wrote:
On 28/01/21 08:17, Xiaoyao Li wrote:
"Active low" means that the bit is usually 1 and goes to 0 when the
condition (such as RTM or bus lock) happens. For almost all those
DR6 bits the value is in fact always 1, but if they a
On 1/27/2021 6:04 PM, Paolo Bonzini wrote:
On 27/01/21 04:41, Xiaoyao Li wrote:
On 1/27/2021 12:31 AM, Paolo Bonzini wrote:
On 08/01/21 07:49, Chenyi Qiang wrote:
To avoid breaking the CPUs without bus lock detection, activate the
DR6_BUS_LOCK bit (bit 11) conditionally in DR6_FIXED_1 bits
On 1/27/2021 12:31 AM, Paolo Bonzini wrote:
On 08/01/21 07:49, Chenyi Qiang wrote:
To avoid breaking the CPUs without bus lock detection, activate the
DR6_BUS_LOCK bit (bit 11) conditionally in DR6_FIXED_1 bits.
The set/clear of DR6_BUS_LOCK is similar to the DR6_RTM in DR6
register. The
On 10/31/2020 8:27 AM, Fenghua Yu wrote:
...
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index 3c70fb34028b..1c3442000972 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -953,6 +953,13 @@ static __always_inline void exc_debug_user(struct pt_regs
*regs,
On 11/3/2020 2:08 PM, Tao Xu wrote:
On 11/3/20 12:43 AM, Andy Lutomirski wrote:
On Sun, Nov 1, 2020 at 10:14 PM Tao Xu wrote:
...
+static int handle_notify(struct kvm_vcpu *vcpu)
+{
+ unsigned long exit_qualification =
vmcs_readl(EXIT_QUALIFICATION);
+
+ /*
+ *
On 11/3/2020 2:25 AM, Paolo Bonzini wrote:
On 02/11/20 19:01, Andy Lutomirski wrote:
What's the point? Surely the kernel should reliably mitigate the
flaw, and the kernel should decide how to do so.
There is some slowdown in trapping #DB and #AC unconditionally. Though
for these two cases
is enabled.
Co-developed-by: Xiaoyao Li
Signed-off-by: Tao Xu
Signed-off-by: Xiaoyao Li
Do you have test cases?
yes we have. The nested #AC (CVE-2015-5307) is a known test case, though
we need to tweak KVM to disable interception #AC for it.
Not yet, because we are waiting real silicon
On 10/22/2020 10:06 PM, Paolo Bonzini wrote:
On 22/10/20 15:31, Xiaoyao Li wrote:
It's common for userspace to copy all supported CPUID bits to
KVM_SET_CPUID2, I don't think this is the right behavior for
KVM_HINTS_REALTIME.
It reminds of X86_FEATURE_WAITPKG, which is added to supported
On 10/22/2020 9:02 PM, Paolo Bonzini wrote:
On 22/10/20 03:34, Wanpeng Li wrote:
From: Wanpeng Li
Per KVM_GET_SUPPORTED_CPUID ioctl documentation:
This ioctl returns x86 cpuid features which are supported by both the
hardware and kvm in its default configuration.
A well-behaved userspace
On 9/3/2020 6:44 AM, Sean Christopherson wrote:
On Tue, Sep 01, 2020 at 10:43:12AM +0200, Vitaly Kuznetsov wrote:
@@ -6809,6 +6824,19 @@ static fastpath_t vmx_vcpu_run(struct kvm_vcpu *vcpu)
if (unlikely(vmx->exit_reason.failed_vmentry))
return EXIT_FASTPATH_NONE;
+
On 8/28/2020 4:56 PM, Chenyi Qiang wrote:
KVM supports the nested VM_{EXIT, ENTRY}_LOAD_IA32_PERF_GLOBAL_CTRL and
VM_{ENTRY_LOAD, EXIT_CLEAR}_BNDCFGS, but they doesn't expose during
the setup of nested VMX controls MSR.
Signed-off-by: Chenyi Qiang
Reviewed-by: Xiaoyao Li
---
arch/x86
On 8/29/2020 9:49 AM, Chenyi Qiang wrote:
On 8/29/2020 1:43 AM, Jim Mattson wrote:
On Fri, Aug 28, 2020 at 1:54 AM Chenyi Qiang
wrote:
KVM supports the nested VM_{EXIT, ENTRY}_LOAD_IA32_PERF_GLOBAL_CTRL and
VM_{ENTRY_LOAD, EXIT_CLEAR}_BNDCFGS, but they doesn't expose during
the setup of
or
sld_fatal when handle_guest_split_lock() is called.
Signed-off-by: Xiaoyao Li
---
The alternative would be to remove the "SLD enabled" check from KVM so
that a truly unexpected/bogus #AC would generate a warn. It's not clear
whether or not calling handle_guest_split_lock() iff SLD
.
Signed-off-by: Xiaoyao Li
---
arch/x86/include/asm/cpu.h | 2 ++
arch/x86/kernel/cpu/intel.c | 12 ++--
arch/x86/kernel/kvm.c | 3 +++
3 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/cpu.h b/arch/x86/include/asm/cpu.h
index 2971a29d5094
. KVM always keeps
SLD bit turned on for guest vcpu. The reason why not force guest
MSR_CTRL.SLD bit to 1 is that guest needs to set this bit to 1 itself
to tell KVM it's SLD-aware.
Signed-off-by: Xiaoyao Li
---
arch/x86/kvm/cpuid.c | 6
arch/x86/kvm/vmx/vmx.c | 68
Unconditionally allow the guest to read and zero-write MSR TEST_CTRL.
This matches the fact that most Intel CPUs support MSR TEST_CTRL, and
it also alleviates the effort to handle wrmsr/rdmsr when split lock
detection is exposed to the guest in a future patch.
Signed-off-by: Xiaoyao Li
It should be more resonable to set cpu_model_supports_sld to true after
BSP is verified to have feature split lock detection.
It also avoids externing the cpu_model_supports_sld when enumerate the
split lock detection in a guest via PV interface in a future patch.
Signed-off-by: Xiaoyao Li
-by: Xiaoyao Li
---
Documentation/virt/kvm/cpuid.rst | 29
arch/x86/include/uapi/asm/kvm_para.h | 8 +---
2 files changed, 26 insertions(+), 11 deletions(-)
diff --git a/Documentation/virt/kvm/cpuid.rst b/Documentation/virt/kvm/cpuid.rst
index a7dff9186bed
-by: Xiaoyao Li
---
arch/x86/include/asm/cpufeatures.h | 1 +
arch/x86/kernel/cpu/intel.c| 16 ++--
2 files changed, 7 insertions(+), 10 deletions(-)
diff --git a/arch/x86/include/asm/cpufeatures.h
b/arch/x86/include/asm/cpufeatures.h
index 2901d5df4366..caf9f4e3e876 100644
handled by wrappers, split_lock_set_guest() and
split_lock_restore_host(), that will be used by KVM when virtualizing
split lock detection for guest in the future.
Signed-off-by: Xiaoyao Li
---
arch/x86/include/asm/cpu.h | 34 ++
arch/x86/kernel/cpu/inte
.
Xiaoyao Li (9):
x86/split_lock: Rename TIF_SLD to TIF_SLD_DISABLED
x86/split_lock: Remove bogus case in handle_guest_split_lock()
x86/split_lock: Introduce flag X86_FEATURE_SLD_FATAL and drop
sld_state
x86/split_lock: Introduce split_lock_virt_switch() and two wrappers
x86/kvm: Introduce
-by: Thomas Gleixner
Signed-off-by: Xiaoyao Li
---
arch/x86/include/asm/thread_info.h | 6 +++---
arch/x86/kernel/cpu/intel.c| 6 +++---
arch/x86/kernel/process.c | 2 +-
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/x86/include/asm/thread_info.h
b/arch/x86/include
On 7/23/2020 9:21 AM, Sean Christopherson wrote:
On Wed, Jul 01, 2020 at 04:49:49PM +0200, Vitaly Kuznetsov wrote:
Xiaoyao Li writes:
So you want an exit to userspace for every bus lock and leave it all to
userspace. Yes, it's doable.
In some cases we may not even want to have a VM exit
On 7/12/2020 2:21 AM, Peter Zijlstra wrote:
On Fri, Jul 03, 2020 at 11:15:31AM -0400, Woody Suwalski wrote:
I am observing a 100% reproducible kvm crash on kernels starting with
5.7-rc1, always with the same opcode .
It happens during wake up from the host suspended state. Worked OK on 5.6
pdate_vcpu_model() [Sean]
- Add patch 5 to rename kvm_x86_ops.cpuid_date() to
kvm_x86_ops.update_vcpu_model()
v1:
https://lkml.kernel.org/r/20200529085545.29242-1-xiaoyao...@intel.com
Xiaoyao Li (5):
KVM: x86: Introduce kvm_check_cpuid()
KVM: x86: Extract kvm_update_cpuid_runtime() fr
Use kvm_check_cpuid() to validate if userspace provides legal cpuid
settings and call it before KVM take any action to update CPUID or
update vcpu states based on given CPUID settings.
Signed-off-by: Xiaoyao Li
---
arch/x86/kvm/cpuid.c | 55
arch/x86
The name of callback cpuid_update() is misleading that it's not about
updating CPUID settings of vcpu but updating the configurations of vcpu
based on the CPUIDs. So rename it to vcpu_after_set_cpuid().
Signed-off-by: Xiaoyao Li
---
arch/x86/include/asm/kvm_host.h | 2 +-
arch/x86/kvm/cpuid.c
Now there is no updating CPUID bits behavior in kvm_update_cpuid(),
rename it to kvm_vcpu_after_set_cpuid().
Signed-off-by: Xiaoyao Li
---
arch/x86/kvm/cpuid.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index
-by: Xiaoyao Li
---
---
arch/x86/kvm/cpuid.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index 832a24c1334e..edbed4f522f2 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -121,6 +121,8 @@ static void
as a separate kvm_update_cpuid_runtime().
Signed-off-by: Xiaoyao Li
---
arch/x86/kvm/cpuid.c | 44 +++-
arch/x86/kvm/cpuid.h | 2 +-
arch/x86/kvm/lapic.c | 2 +-
arch/x86/kvm/x86.c | 10 +-
4 files changed, 34 insertions(+), 24 deletions(-)
diff
On 7/8/2020 8:10 PM, Paolo Bonzini wrote:
On 08/07/20 08:50, Xiaoyao Li wrote:
This serial is the extended version of
https://lkml.kernel.org/r/20200528151927.14346-1-xiaoyao...@intel.com
First two patches are bug fixing, and the others aim to refactor the flow
of SET_CPUID* as:
1. cpuid
On 7/8/2020 8:41 PM, Paolo Bonzini wrote:
On 08/07/20 14:33, Xiaoyao Li wrote:
On 7/8/2020 8:06 PM, Paolo Bonzini wrote:
On 08/07/20 08:50, Xiaoyao Li wrote:
Split the part of updating vcpu model out of kvm_update_cpuid(), and put
it into a new kvm_update_vcpu_model(). So it's more clear
On 7/8/2020 8:06 PM, Paolo Bonzini wrote:
On 08/07/20 08:50, Xiaoyao Li wrote:
Split the part of updating vcpu model out of kvm_update_cpuid(), and put
it into a new kvm_update_vcpu_model(). So it's more clear that
kvm_update_cpuid() is to update guest CPUID settings, while
On 7/8/2020 2:50 PM, Xiaoyao Li wrote:
Use kvm_check_cpuid() to validate if userspace provides legal cpuid
settings and call it before KVM updates CPUID.
Signed-off-by: Xiaoyao Li
[...]
@@ -202,12 +208,16 @@ int kvm_vcpu_ioctl_set_cpuid(struct kvm_vcpu *vcpu,
vcpu
On 7/3/2020 5:38 AM, Abhishek Bhardwaj wrote:
This change adds a new kernel configuration that sets the l1d cache
flush setting at compile time rather than at run time.
Signed-off-by: Abhishek Bhardwaj
---
Changes in v2:
- Fix typo in the help of the new KConfig.
.
Signed-off-by: Xiaoyao Li
---
arch/x86/kvm/cpuid.c | 38 --
arch/x86/kvm/cpuid.h | 1 +
arch/x86/kvm/x86.c | 1 +
3 files changed, 26 insertions(+), 14 deletions(-)
diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index a825878b7f84..001f5a94880e 100644
There is no dependencies between kvm_apic_set_version() and
kvm_update_cpuid() because kvm_apic_set_version() queries X2APIC CPUID bit,
which is not touched/changed by kvm_update_cpuid().
Obviously, kvm_apic_set_version() belongs to the category of updating
vcpu model.
Signed-off-by: Xiaoyao Li
reasonable.
Signed-off-by: Xiaoyao Li
---
---
arch/x86/kvm/cpuid.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index d2f93823f9fd..89ffd9dccfc6 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -121,6 +121,8
Only code cleanup and no functional change.
Signed-off-by: Xiaoyao Li
---
arch/x86/kvm/lapic.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 5bf72fc86a8e..e5dbb7ebae78 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm
Use kvm_check_cpuid() to validate if userspace provides legal cpuid
settings and call it before KVM updates CPUID.
Signed-off-by: Xiaoyao Li
---
Is the check of virutal address width really necessary?
KVM doesn't check other bits at all. I guess the policy is that KVM allows
illegal CPUID
out of this
function in a future patch.
Signed-off-by: Xiaoyao Li
---
arch/x86/kvm/cpuid.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index 1d13bad42bf9..0e3a23c2ea55 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/
The name of callback cpuid_update() is misleading that it's not about
updating CPUID settings of vcpu but updating the configurations of vcpu
based on the CPUIDs. So rename it to update_vcpu_model().
Signed-off-by: Xiaoyao Li
---
arch/x86/include/asm/kvm_host.h | 2 +-
arch/x86/kvm/cpuid.c
rantee that previous valid CPUID configuration is
kept.
Signed-off-by: Xiaoyao Li
---
Documentation/virt/kvm/api.rst | 4
arch/x86/kvm/cpuid.c | 4
2 files changed, 8 insertions(+)
diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
index 1cfe79b932d6..3ca809
aster' into HEAD")
- change the name of kvm_update_state_based_on_cpuid() to
kvm_update_vcpu_model() [Sean]
- Add patch 5 to rename kvm_x86_ops.cpuid_date() to
kvm_x86_ops.update_vcpu_model()
v1:
https://lkml.kernel.org/r/20200529085545.29242-1-xiaoyao...@intel.com
Xiaoyao Li (8):
On 7/8/2020 4:21 AM, Sean Christopherson wrote:
On Sat, Jun 13, 2020 at 05:42:50PM +0800, Xu, Like wrote:
On 2020/6/13 17:14, Xiaoyao Li wrote:
On 6/13/2020 4:09 PM, Like Xu wrote:
[...]
@@ -237,6 +238,9 @@ static int intel_pmu_get_msr(struct kvm_vcpu *vcpu,
struct msr_data *msr_info
On 7/3/2020 3:00 AM, Sean Christopherson wrote:
On Tue, Jun 23, 2020 at 07:58:16PM +0800, Xiaoyao Li wrote:
Obviously, kvm_apic_set_version() fits well in kvm_update_vcpu_model().
Same as the last patch, it would be nice to explicitly document that there
are no dependencies between
On 7/3/2020 2:59 AM, Sean Christopherson wrote:
On Tue, Jun 23, 2020 at 07:58:15PM +0800, Xiaoyao Li wrote:
kvm_x86_ops.update_vcpu_model() is used to update vmx/svm vcpu settings
based on updated CPUID settings. So it's supposed to be called after
CPUIDs are fully updated, i.e
On 7/3/2020 3:02 AM, Sean Christopherson wrote:
On Thu, Jul 02, 2020 at 11:54:03AM -0700, Sean Christopherson wrote:
On Tue, Jun 23, 2020 at 07:58:11PM +0800, Xiaoyao Li wrote:
As handling of bits other leaf 1 added over time, kvm_update_cpuid()
should not return directly if leaf 1 is absent
On 7/1/2020 4:04 PM, Yang Weijiang wrote:
CET MSRs pass through guest directly to enhance performance. CET runtime
control settings are stored in MSR_IA32_{U,S}_CET, Shadow Stack Pointer(SSP)
are stored in MSR_IA32_PL{0,1,2,3}_SSP, SSP table base address is stored in
MSR_IA32_INT_SSP_TAB, these
On 7/1/2020 10:49 PM, Vitaly Kuznetsov wrote:
Xiaoyao Li writes:
On 7/1/2020 8:44 PM, Vitaly Kuznetsov wrote:
Xiaoyao Li writes:
On 7/1/2020 5:04 PM, Vitaly Kuznetsov wrote:
Chenyi Qiang writes:
[...]
static const int kvm_vmx_max_exit_handlers =
@@ -6830,6 +6838,13 @@ static
On 7/1/2020 8:44 PM, Vitaly Kuznetsov wrote:
Xiaoyao Li writes:
On 7/1/2020 5:04 PM, Vitaly Kuznetsov wrote:
Chenyi Qiang writes:
[...]
static const int kvm_vmx_max_exit_handlers =
@@ -6830,6 +6838,13 @@ static fastpath_t vmx_vcpu_run(struct kvm_vcpu *vcpu)
if (unlikely(vmx
On 7/1/2020 5:04 PM, Vitaly Kuznetsov wrote:
Chenyi Qiang writes:
[...]
static const int kvm_vmx_max_exit_handlers =
@@ -6830,6 +6838,13 @@ static fastpath_t vmx_vcpu_run(struct kvm_vcpu *vcpu)
if (unlikely(vmx->exit_reason.failed_vmentry))
return EXIT_FASTPATH_NONE;
Ping for comments.
On 5/9/2020 7:05 PM, Xiaoyao Li wrote:
This series aims to add the virtualization of split lock detection in
KVM.
Due to the fact that split lock detection is tightly coupled with CPU
model and CPU model is configurable by host VMM, we elect to use
paravirt method to expose
On 6/24/2020 2:20 AM, Jim Mattson wrote:
On Tue, Jun 23, 2020 at 4:58 AM Xiaoyao Li wrote:
It needs to invalidate CPUID configruations if usersapce provides
Nits: configurations, userspace
oh, I'll fix it.
illegal input.
Signed-off-by: Xiaoyao Li
---
arch/x86/kvm/cpuid.c | 4
As handling of bits other leaf 1 added over time, kvm_update_cpuid()
should not return directly if leaf 1 is absent, but should go on
updateing other CPUID leaves.
Signed-off-by: Xiaoyao Li
---
arch/x86/kvm/cpuid.c | 23 +++
1 file changed, 11 insertions(+), 12 deletions
.
Signed-off-by: Xiaoyao Li
---
arch/x86/kvm/cpuid.c | 38 --
arch/x86/kvm/cpuid.h | 1 +
arch/x86/kvm/x86.c | 1 +
3 files changed, 26 insertions(+), 14 deletions(-)
diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index 67e5c68fdb45..001f5a94880e 100644
Use kvm_check_cpuid() to validate if userspace provides legal cpuid
settings and call it before KVM updates CPUID.
Signed-off-by: Xiaoyao Li
---
Is the check of virutal address width really necessary?
KVM doesn't check other bits at all. I guess the policy is that KVM allows
illegal CPUID
The name of callback cpuid_update() is misleading that it's not about
updating CPUID settings of vcpu but updating the configurations of vcpu
based on the CPUIDs. So rename it to update_vcpu_model().
Signed-off-by: Xiaoyao Li
---
arch/x86/include/asm/kvm_host.h | 2 +-
arch/x86/kvm/cpuid.c
It needs to invalidate CPUID configruations if usersapce provides
illegal input.
Signed-off-by: Xiaoyao Li
---
arch/x86/kvm/cpuid.c | 4
1 file changed, 4 insertions(+)
diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index 8a294f9747aa..1d13bad42bf9 100644
--- a/arch/x86/kvm
- change the name of kvm_update_state_based_on_cpuid() to
kvm_update_vcpu_model() [Sean]
- Add patch 5 to rename kvm_x86_ops.cpuid_date() to
kvm_x86_ops.update_vcpu_model()
v1:
https://lkml.kernel.org/r/20200529085545.29242-1-xiaoyao...@intel.com
Xiaoyao Li (7):
KVM: X86: Reset vcpu->ar
Obviously, kvm_apic_set_version() fits well in kvm_update_vcpu_model().
Signed-off-by: Xiaoyao Li
---
arch/x86/kvm/cpuid.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index 5decc2dd5448..3428f4d84b42 100644
--- a/arch/x86
kvm_x86_ops.update_vcpu_model() is used to update vmx/svm vcpu settings
based on updated CPUID settings. So it's supposed to be called after
CPUIDs are fully updated, i.e., kvm_update_cpuid().
Move it in kvm_update_vcpu_model().
Signed-off-by: Xiaoyao Li
---
---
arch/x86/kvm/cpuid.c | 5
On 6/23/2020 8:51 AM, Sean Christopherson wrote:
Remove support for context switching between the guest's and host's
desired UMWAIT_CONTROL. Propagating the guest's value to hardware isn't
required for correct functionality, e.g. KVM intercepts reads and writes
to the MSR, and the latency
Only MSR address range 0x800 through 0x8ff is architecturally reserved
and dedicated for accessing APIC registers in x2APIC mode.
Fixes: 0105d1a52640 ("KVM: x2apic interface to lapic")
Signed-off-by: Xiaoyao Li
---
arch/x86/kvm/x86.c | 4 ++--
1 file changed, 2 insertions(+), 2
On 6/13/2020 4:09 PM, Like Xu wrote:
When the LBR feature is reported by the vmx_get_perf_capabilities(),
the LBR fields in the [vmx|vcpu]_supported debugctl should be unmasked.
The debugctl msr is handled separately in vmx/svm and they're not
completely identical, hence remove the common msr
On 6/6/2020 12:42 AM, Prarit Bhargava wrote:
On 6/5/20 11:29 AM, Xiaoyao Li wrote:
On 6/5/2020 7:44 PM, Prarit Bhargava wrote:
There are two problems with kernel messages in fatal mode that
were found during testing of guests and userspace programs.
The first is that no kernel message
On 6/6/2020 3:26 AM, Sean Christopherson wrote:
Choo! Choo! All aboard the Split Lock Express, with direct service to
Wreckage!
Skip split_lock_verify_msr() if the CPU isn't whitelisted as a possible
SLD-enabled CPU model to avoid writing MSR_TEST_CTRL. MSR_TEST_CTRL
exists, and is writable,
Molnar
Cc: Borislav Petkov
Cc: x...@kernel.org
Cc: "H. Peter Anvin"
Cc: Tony Luck
Cc: "Peter Zijlstra (Intel)"
Cc: Sean Christopherson
Cc: Rahul Tanwar
Cc: Xiaoyao Li
Cc: Ricardo Neri
Cc: Dave Hansen
---
arch/x86/kernel/cpu/intel.c | 24 ++--
On 6/5/2020 9:44 AM, Li RongQing wrote:
Guest kernel reports a fixed cpu frequency in /proc/cpuinfo,
this is confused to user when turbo is enable, and aperf/mperf
can be used to show current cpu frequency after 7d5905dc14a
"(x86 / CPU: Always show current CPU frequency in /proc/cpuinfo)"
so
Delay the assignment of array.maxnent to use correct value for the case
cpuid->nent > KVM_MAX_CPUID_ENTRIES.
Fixes: e53c95e8d41e ("KVM: x86: Encapsulate CPUID entries and metadata in
struct")
Signed-off-by: Xiaoyao Li
---
v2:
- remove "const" of maxnent to fix buil
On 6/4/2020 10:43 AM, Xiaoyao Li wrote:
Delay the assignment of array.maxnent to use correct value for the case
cpuid->nent > KVM_MAX_CPUID_ENTRIES.
Fixes: e53c95e8d41e ("KVM: x86: Encapsulate CPUID entries and metadata in
struct")
Signed-off-by: Xiaoyao Li
---
arch/x86
Delay the assignment of array.maxnent to use correct value for the case
cpuid->nent > KVM_MAX_CPUID_ENTRIES.
Fixes: e53c95e8d41e ("KVM: x86: Encapsulate CPUID entries and metadata in
struct")
Signed-off-by: Xiaoyao Li
---
arch/x86/kvm/cpuid.c | 3 ++-
1 file changed, 2
On 6/3/2020 9:10 AM, Sean Christopherson wrote:
On Fri, May 29, 2020 at 04:55:43PM +0800, Xiaoyao Li wrote:
Split the part of updating KVM states from kvm_update_cpuid(), and put
it into a new kvm_update_state_based_on_cpuid(). So it's clear that
kvm_update_cpuid() is to update guest CPUID
On 5/31/2020 10:08 AM, Li,Rongqing wrote:
-邮件原件-
发件人: Xiaoyao Li [mailto:xiaoyao...@intel.com]
发送时间: 2020年5月30日 18:40
收件人: Li,Rongqing ; linux-kernel@vger.kernel.org;
k...@vger.kernel.org; x...@kernel.org; h...@zytor.com; b...@alien8.de;
mi...@redhat.com; t...@linutronix.de; jmatt
On 5/30/2020 12:35 PM, Li RongQing wrote:
Guest kernel reports a fixed cpu frequency in /proc/cpuinfo,
this is confused to user when turbo is enable, and aperf/mperf
can be used to show current cpu frequency after 7d5905dc14a
"(x86 / CPU: Always show current CPU frequency in /proc/cpuinfo)"
so
specific states based on CPUID.
Signed-off-by: Xiaoyao Li
---
Should we rename kvm_x86_ops.cpuid_update to something like
kvm_x86_ops.update_state_based_on_cpuid?
cpuid_update is really confusing especially when kvm_x86_ops.update_cpuid()
is needed someday.
---
arch/x86/kvm/cpuid.c | 4 ++--
1
As handling of bits other leaf 1 added over time, kvm_update_cpuid()
should not return directly if leaf 1 is absent, but should go on
updateing other CPUID leaves.
Signed-off-by: Xiaoyao Li
---
arch/x86/kvm/cpuid.c | 23 +++
1 file changed, 11 insertions(+), 12 deletions
special CPUID bits based on current vcpu
state, e.g., OSXSAVE, OSPKE, ...
3. update KVM state: Update KVM states based on the final CPUID
settings.
Xiaoyao Li (6):
KVM: X86: Reset vcpu->arch.cpuid_nent to 0 if SET_CPUID fails
KVM: X86: Go on updating ot
.
Signed-off-by: Xiaoyao Li
---
arch/x86/kvm/cpuid.c | 38 --
arch/x86/kvm/cpuid.h | 1 +
arch/x86/kvm/x86.c | 1 +
3 files changed, 26 insertions(+), 14 deletions(-)
diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index c8cb373056f1..a4a2072f5253
It needs to invalidate CPUID configruations if usersapce provides
illegal input.
Signed-off-by: Xiaoyao Li
---
arch/x86/kvm/cpuid.c | 4
1 file changed, 4 insertions(+)
diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index cd708b0b460a..2f1a9650b7f2 100644
--- a/arch/x86/kvm
Obviously, kvm_apic_set_version() fits well in
kvm_update_state_based_on_cpuid().
Signed-off-by: Xiaoyao Li
---
arch/x86/kvm/cpuid.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index 5d4da8970940..eb60098aca29 100644
Use kvm_check_cpuid() to validate if userspace provides legal cpuid
settings and call it before KVM updates CPUID.
Signed-off-by: Xiaoyao Li
---
Is the check of virutal address width really necessary?
KVM doesn't check other bits at all. I guess the policy is that KVM allows
illegal CPUID
On 5/29/2020 12:15 AM, Paolo Bonzini wrote:
On 28/05/20 17:40, Xiaoyao Li wrote:
kvm_x86_ops.cpuid_update() is used to update vmx/svm settings based on
updated CPUID settings. So it's supposed to be called after CPUIDs are
fully updated, not in the middle stage.
Signed-off-by: Xiaoyao Li
On 5/28/2020 11:22 PM, Paolo Bonzini wrote:
On 28/05/20 17:19, Xiaoyao Li wrote:
kvm_x86_ops.cpuid_update() is used to update vmx/svm settings based on
updated CPUID settings. So it's supposed to be called after CPUIDs are
fully updated, not in the middle stage.
Signed-off-by: Xiaoyao Li
kvm_x86_ops.cpuid_update() is used to update vmx/svm settings based on
updated CPUID settings. So it's supposed to be called after CPUIDs are
fully updated, not in the middle stage.
Signed-off-by: Xiaoyao Li
---
arch/x86/kvm/cpuid.c | 10 --
1 file changed, 8 insertions(+), 2 deletions
Hi Thomas,
On 5/18/2020 9:27 AM, Xiaoyao Li wrote:
On 5/9/2020 7:05 PM, Xiaoyao Li wrote:
This series aims to add the virtualization of split lock detection in
KVM.
Due to the fact that split lock detection is tightly coupled with CPU
model and CPU model is configurable by host VMM, we elect
On 5/21/2020 12:56 AM, Maxim Levitsky wrote:
On Wed, 2020-05-20 at 18:33 +0200, Vitaly Kuznetsov wrote:
Maxim Levitsky writes:
This msr is only available when the host supports WAITPKG feature.
This breaks a nested guest, if the L1 hypervisor is set to ignore
unknown msrs, because the only
On 5/21/2020 1:28 PM, Tao Xu wrote:
On 5/21/2020 12:33 PM, Xiaoyao Li wrote:
On 5/21/2020 5:05 AM, Paolo Bonzini wrote:
On 20/05/20 18:07, Maxim Levitsky wrote:
This msr is only available when the host supports WAITPKG feature.
This breaks a nested guest, if the L1 hypervisor is set
On 5/21/2020 5:05 AM, Paolo Bonzini wrote:
On 20/05/20 18:07, Maxim Levitsky wrote:
This msr is only available when the host supports WAITPKG feature.
This breaks a nested guest, if the L1 hypervisor is set to ignore
unknown msrs, because the only other safety check that the
kernel does is
On 5/18/2020 8:31 PM, Paolo Bonzini wrote:
On 18/05/20 06:52, Xiaoyao Li wrote:
On 5/6/2020 5:44 PM, Paolo Bonzini wrote:
Using CPUID data can be useful for the processor compatibility
check, but that's it. Using it to compute guest-reserved bits
can have both false positives (such as LA57
On 5/6/2020 5:44 PM, Paolo Bonzini wrote:
Using CPUID data can be useful for the processor compatibility
check, but that's it. Using it to compute guest-reserved bits
can have both false positives (such as LA57 and UMIP which we
are already handling) and false negatives:
in particular, with
On 5/9/2020 7:05 PM, Xiaoyao Li wrote:
This series aims to add the virtualization of split lock detection in
KVM.
Due to the fact that split lock detection is tightly coupled with CPU
model and CPU model is configurable by host VMM, we elect to use
paravirt method to expose and enumerate
On 5/10/2020 1:15 PM, Andy Lutomirski wrote:
On Fri, May 8, 2020 at 8:04 PM Xiaoyao Li wrote:
When running as guest, enumerating feature split lock detection through
CPU model is not easy since CPU model is configurable by host VMM.
If running upon KVM, it can be enumerated through
-by: Xiaoyao Li
---
arch/x86/include/asm/cpufeatures.h | 1 +
arch/x86/kernel/cpu/intel.c| 16 ++--
2 files changed, 7 insertions(+), 10 deletions(-)
diff --git a/arch/x86/include/asm/cpufeatures.h
b/arch/x86/include/asm/cpufeatures.h
index db189945e9b0..260adfc6c61a 100644
. KVM always keeps
SLD bit turned on for guest vcpu. The reason why not force guest
MSR_CTRL.SLD bit to 1 is that guest needs to set this bit to 1 itself
to tell KVM it's SLD-aware.
Signed-off-by: Xiaoyao Li
---
arch/x86/kvm/cpuid.c | 6
arch/x86/kvm/vmx/vmx.c | 68
.
Signed-off-by: Xiaoyao Li
---
arch/x86/include/asm/cpu.h | 2 ++
arch/x86/kernel/cpu/intel.c | 12 ++--
arch/x86/kernel/kvm.c | 3 +++
3 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/cpu.h b/arch/x86/include/asm/cpu.h
index a57f00f1d5b5
1 - 100 of 201 matches
Mail list logo
