From: Wanpeng Li
vCPUs are very unlikely to get preempted when they are the only task
running on a CPU. PV TLB flush is slower that the native flush in that
case. In addition, avoid traversing all the cpus for pv tlb flush when
steal time is disabled since pv tlb flush depends on the field
From: Wanpeng Li
Waiman Long mentioned that:
Generally speaking, unfair lock performs well for VMs with a small
number of vCPUs. Native qspinlock may perform better than pvqspinlock
if there is vCPU pinning and there is no vCPU over-commitment.
This patch uses a KVM_HINTS_DEDICATED
v1 -> v2:
* update to KVM_HINTS_DEDICATED
Wanpeng Li (3):
KVM: Introduce dedicated vCPUs hint KVM_HINTS_DEDICATED
KVM: X86: Choose qspinlock when dedicated vCPUs available
KVM: X86: Don't use PV TLB flush with dedicated vCPUs and steal time
disabled
Documentation/virtual/kvm/cpuid.txt
v1 -> v2:
* update to KVM_HINTS_DEDICATED
Wanpeng Li (3):
KVM: Introduce dedicated vCPUs hint KVM_HINTS_DEDICATED
KVM: X86: Choose qspinlock when dedicated vCPUs available
KVM: X86: Don't use PV TLB flush with dedicated vCPUs and steal time
disabled
Documentation/virtual/kvm/cpuid.txt
From: Wanpeng Li <wanpen...@tencent.com>
vCPUs are very unlikely to get preempted when they are the only task
running on a CPU. PV TLB flush is slower that the native flush in that
case. In addition, avoid traversing all the cpus for pv tlb flush when
steal time is disabled since pv tlb
From: Wanpeng Li
vCPUs are very unlikely to get preempted when they are the only task
running on a CPU. PV TLB flush is slower that the native flush in that
case. In addition, avoid traversing all the cpus for pv tlb flush when
steal time is disabled since pv tlb flush depends on the field
From: Wanpeng Li <wanpen...@tencent.com>
Waiman Long mentioned that:
Generally speaking, unfair lock performs well for VMs with a small
number of vCPUs. Native qspinlock may perform better than pvqspinlock
if there is vCPU pinning and there is no vCPU over-commitment.
This patc
From: Wanpeng Li
Waiman Long mentioned that:
Generally speaking, unfair lock performs well for VMs with a small
number of vCPUs. Native qspinlock may perform better than pvqspinlock
if there is vCPU pinning and there is no vCPU over-commitment.
This patch adds a performance hint to allow
From: Wanpeng Li <wanpen...@tencent.com>
Add KVM_HINTS_DEDICATED performance hint, guest checks this feature bit
to determine if they run on dedicated vCPUs, allowing optimizations such
as usage of qspinlocks.
Cc: Paolo Bonzini <pbonz...@redhat.com>
Cc: Radim Krčmář <rkrc...
From: Wanpeng Li
Add KVM_HINTS_DEDICATED performance hint, guest checks this feature bit
to determine if they run on dedicated vCPUs, allowing optimizations such
as usage of qspinlocks.
Cc: Paolo Bonzini
Cc: Radim Krčmář
Cc: Eduardo Habkost
Signed-off-by: Wanpeng Li
---
v1 -> v2:
*
2018-02-07 22:16 GMT+08:00 Paolo Bonzini <pbonz...@redhat.com>:
> On 07/02/2018 07:25, Wanpeng Li wrote:
>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
>> index 786cd00..445e702 100644
>> --- a/arch/x86/kvm/x86.c
>> +++ b/arch/x86/kvm/x8
2018-02-07 22:16 GMT+08:00 Paolo Bonzini :
> On 07/02/2018 07:25, Wanpeng Li wrote:
>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
>> index 786cd00..445e702 100644
>> --- a/arch/x86/kvm/x86.c
>> +++ b/arch/x86/kvm/x86.c
>> @@ -7458,6 +7458,11 @@ int kvm_ar
From: Wanpeng Li <wanpen...@tencent.com>
Reported by syzkaller:
WARNING: CPU: 6 PID: 2434 at arch/x86/kvm/vmx.c:6660
handle_ept_misconfig+0x54/0x1e0 [kvm_intel]
CPU: 6 PID: 2434 Comm: repro_test Not tainted 4.15.0+ #4
RIP: 0010:handle_ept_misconfig+0x54/0x1e0 [kvm_intel]
Call
From: Wanpeng Li
Reported by syzkaller:
WARNING: CPU: 6 PID: 2434 at arch/x86/kvm/vmx.c:6660
handle_ept_misconfig+0x54/0x1e0 [kvm_intel]
CPU: 6 PID: 2434 Comm: repro_test Not tainted 4.15.0+ #4
RIP: 0010:handle_ept_misconfig+0x54/0x1e0 [kvm_intel]
Call Trace:
vmx_handle_exit
ven
if vmcs shadow is enabled since host_cr[34] is not shadowed in the
bitmap, why it is not up-to-date when L1 is running?
Regards,
Wanpeng Li
> they are legal (because we checked them), but that's about it. If the
> VMLAUNCH/VMRESUME of vmcs12 fails for "invalid control field," t
e host_cr[34] is not shadowed in the
bitmap, why it is not up-to-date when L1 is running?
Regards,
Wanpeng Li
> they are legal (because we checked them), but that's about it. If the
> VMLAUNCH/VMRESUME of vmcs12 fails for "invalid control field," there
> is no VM-exit
2018-02-07 0:58 GMT+08:00 Jim Mattson <jmatt...@google.com>:
> On Mon, Feb 5, 2018 at 4:57 PM, Wanpeng Li <kernel...@gmail.com> wrote:
>
>> This is effective one, what I restore in this patch is
>> achitectural/guest visible.
>
> This patch doesn't "re
2018-02-07 0:58 GMT+08:00 Jim Mattson :
> On Mon, Feb 5, 2018 at 4:57 PM, Wanpeng Li wrote:
>
>> This is effective one, what I restore in this patch is
>> achitectural/guest visible.
>
> This patch doesn't "restore" the guest visible CR4 to its value at the
>
From: Wanpeng Li <wanpen...@tencent.com>
Reported by syzkaller:
WARNING: CPU: 6 PID: 2434 at arch/x86/kvm/vmx.c:6660
handle_ept_misconfig+0x54/0x1e0 [kvm_intel]
CPU: 6 PID: 2434 Comm: repro_test Not tainted 4.15.0+ #4
RIP: 0010:handle_ept_misconfig+0x54/0x1e0 [kvm_intel]
Call
From: Wanpeng Li
Reported by syzkaller:
WARNING: CPU: 6 PID: 2434 at arch/x86/kvm/vmx.c:6660
handle_ept_misconfig+0x54/0x1e0 [kvm_intel]
CPU: 6 PID: 2434 Comm: repro_test Not tainted 4.15.0+ #4
RIP: 0010:handle_ept_misconfig+0x54/0x1e0 [kvm_intel]
Call Trace:
vmx_handle_exit
gt; handle_ept_misconfig+0x140/0x520 arch/x86/kvm/vmx.c:6771
> Kernel panic - not syncing: panic_on_warn set ...
I can reproduce, will have a look.
Regards,
Wanpeng Li
>
> CPU: 0 PID: 4187 Comm: syzkaller225100 Not tainted 4.15.0+ #298
> Hardware name: Google Google Com
nic - not syncing: panic_on_warn set ...
I can reproduce, will have a look.
Regards,
Wanpeng Li
>
> CPU: 0 PID: 4187 Comm: syzkaller225100 Not tainted 4.15.0+ #298
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> __dump_st
return 1;
There is a scenario here, UMIP CPUID is not exposed to the guest since
it depends on SECONDARY_EXEC_DESC is set, however, SECONDARY_EXEC_DESC
depends on guest sets the X86_CR4_UMIP bit, the function kvm_set_cr4()
will inject a #GP and fails to set X86_CR4_UMIP bit since UMIP CPUID
is not exposed to the guest. This scenario can be observed when
running kvm-unit-tests/umip.flat in the L1.
Regards,
Wanpeng Li
PUID is not exposed to the guest since
it depends on SECONDARY_EXEC_DESC is set, however, SECONDARY_EXEC_DESC
depends on guest sets the X86_CR4_UMIP bit, the function kvm_set_cr4()
will inject a #GP and fails to set X86_CR4_UMIP bit since UMIP CPUID
is not exposed to the guest. This scenario can be observed when
running kvm-unit-tests/umip.flat in the L1.
Regards,
Wanpeng Li
ware.
>
>> CR4 should be unchanged from the time of the VMLAUNCH/VMRESUME. There is
This is effective one, what I restore in this patch is
achitectural/guest visible.
Regards,
Wanpeng Li
>> no guarantee that vmcs12->host_cr4 holds the correct value.
>
>
>> On Mon,
he VMLAUNCH/VMRESUME. There is
This is effective one, what I restore in this patch is
achitectural/guest visible.
Regards,
Wanpeng Li
>> no guarantee that vmcs12->host_cr4 holds the correct value.
>
>
>> On Mon, Feb 5, 2018 at 3:05 AM Wanpeng Li wrote:
>
>>> F
From: Wanpeng Li <wanpen...@tencent.com>
In L0, Haswell client host:
nested_vmx_exit_reflected failed vm entry 7
WARNING: CPU: 6 PID: 6797 at kvm/arch/x86/kvm//vmx.c:6206
handle_desc+0x2d/0x40 [kvm_intel]
CPU: 6 PID: 6797 Comm: qemu-system-x86 Tainted: GW OE4.15.0+ #4
RIP
From: Wanpeng Li
In L0, Haswell client host:
nested_vmx_exit_reflected failed vm entry 7
WARNING: CPU: 6 PID: 6797 at kvm/arch/x86/kvm//vmx.c:6206
handle_desc+0x2d/0x40 [kvm_intel]
CPU: 6 PID: 6797 Comm: qemu-system-x86 Tainted: GW OE4.15.0+ #4
RIP: 0010:handle_desc+0x2d/0x40
2018-02-03 3:02 GMT+08:00 Radim Krčmář <rkrc...@redhat.com>:
> 2018-02-01 23:11-0800, Wanpeng Li:
>> From: Wanpeng Li <wanpen...@tencent.com>
>>
>> If host CPUs are dedicated to a VM, we can avoid VM exits on HLT.
>> This patch adds the per-VM non-HLT-exit
2018-02-03 3:02 GMT+08:00 Radim Krčmář :
> 2018-02-01 23:11-0800, Wanpeng Li:
>> From: Wanpeng Li
>>
>> If host CPUs are dedicated to a VM, we can avoid VM exits on HLT.
>> This patch adds the per-VM non-HLT-exiting capability.
>>
>> Cc: Paolo Bonz
From: Wanpeng Li <wanpen...@tencent.com>
If host CPUs are dedicated to a VM, we can avoid VM exits on HLT.
This patch adds the per-VM non-HLT-exiting capability.
Cc: Paolo Bonzini <pbonz...@redhat.com>
Cc: Radim Krčmář <rkrc...@redhat.com>
Signed-off-by: Wanpeng Li <wanpen..
From: Wanpeng Li
If host CPUs are dedicated to a VM, we can avoid VM exits on HLT.
This patch adds the per-VM non-HLT-exiting capability.
Cc: Paolo Bonzini
Cc: Radim Krčmář
Signed-off-by: Wanpeng Li
---
v1 -> v2:
* vmx_clear_hlt() around INIT handling
* vmx_clear_hlt() upon
From: Wanpeng Li <wanpen...@tencent.com>
Avoid traversing all the cpus for pv tlb flush when steal time
is disabled since pv tlb flush depends on the field in steal time
for shared data.
Cc: Paolo Bonzini <pbonz...@redhat.com>
Cc: Radim Krčmář <rkrc...@redhat.com>
Signed-
From: Wanpeng Li
Avoid traversing all the cpus for pv tlb flush when steal time
is disabled since pv tlb flush depends on the field in steal time
for shared data.
Cc: Paolo Bonzini
Cc: Radim Krčmář
Signed-off-by: Wanpeng Li
---
arch/x86/kernel/kvm.c | 6 --
1 file changed, 4
From: Wanpeng Li <wanpen...@tencent.com>
If host CPUs are dedicated to a VM, we can avoid VM exits on HLT.
This patch adds the per-VM non-HLT-exiting capability.
Cc: Paolo Bonzini <pbonz...@redhat.com>
Cc: Radim Krčmář <rkrc...@redhat.com>
Signed-off-by: Wanpeng Li <
From: Wanpeng Li
If host CPUs are dedicated to a VM, we can avoid VM exits on HLT.
This patch adds the per-VM non-HLT-exiting capability.
Cc: Paolo Bonzini
Cc: Radim Krčmář
Signed-off-by: Wanpeng Li
---
Documentation/virtual/kvm/api.txt | 11 +++
arch/x86/include/asm/kvm_host.h
From: Wanpeng Li <wanpen...@tencent.com>
Waiman Long mentioned that:
Generally speaking, unfair lock performs well for VMs with a small
number of vCPUs. Native qspinlock may perform better than pvqspinlock
if there is vCPU pinning and there is no vCPU over-commitment.
This patc
From: Wanpeng Li
Waiman Long mentioned that:
Generally speaking, unfair lock performs well for VMs with a small
number of vCPUs. Native qspinlock may perform better than pvqspinlock
if there is vCPU pinning and there is no vCPU over-commitment.
This patch adds a performance hint to allow
performance
under the dedicated pCPU scenarios.
Wanpeng Li (2):
KVM: X86: Add dedicated pCPU hint PV_DEDICATED
KVM: X86: Add per-VM no-HLT-exiting capability
Documentation/virtual/kvm/api.txt| 11 +++
Documentation/virtual/kvm/cpuid.txt | 6 ++
arch/x86/include/asm/kvm_host.h
performance
under the dedicated pCPU scenarios.
Wanpeng Li (2):
KVM: X86: Add dedicated pCPU hint PV_DEDICATED
KVM: X86: Add per-VM no-HLT-exiting capability
Documentation/virtual/kvm/api.txt| 11 +++
Documentation/virtual/kvm/cpuid.txt | 6 ++
arch/x86/include/asm/kvm_host.h
g different cases, we are checking for CPUID feature bit
> before enabling the feature and nothing else.
>
> Fixes: 52a5c155cf79 ("KVM: async_pf: Let guest support delivery of async_pf
> from guest mode")
> Cc: <sta...@vger.kernel.org>
> Signed-off-by: Radim Krčmá
cking for CPUID feature bit
> before enabling the feature and nothing else.
>
> Fixes: 52a5c155cf79 ("KVM: async_pf: Let guest support delivery of async_pf
> from guest mode")
> Cc:
> Signed-off-by: Radim Krčmář
Reviewed-by: Wanpeng Li
> ---
> v2:
> * ad
fast mmio when running nested.
>
> Signed-off-by: Vitaly Kuznetsov <vkuzn...@redhat.com>
Reviewed-by: Wanpeng Li <wanpeng...@hotmail.com>
> ---
> arch/x86/kvm/vmx.c | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/kvm/vmx.c
ted.
>
> Signed-off-by: Vitaly Kuznetsov
Reviewed-by: Wanpeng Li
> ---
> arch/x86/kvm/vmx.c | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> index c829d89e2e63..54afb446f38e 100644
> --- a/arc
2018-01-23 21:49 GMT+08:00 Mike Galbraith <efa...@gmx.de>:
> On Tue, 2018-01-23 at 18:36 +0800, Wanpeng Li wrote:
>>
>> Thanks for having a try, Mike. :) Actually the two context1 tasks
>> don't stack up on one logical cpu at the most of time which is
>> observe
2018-01-23 21:49 GMT+08:00 Mike Galbraith :
> On Tue, 2018-01-23 at 18:36 +0800, Wanpeng Li wrote:
>>
>> Thanks for having a try, Mike. :) Actually the two context1 tasks
>> don't stack up on one logical cpu at the most of time which is
>> observed by kernelshar
2018-01-22 21:37 GMT+08:00 Mike Galbraith <efa...@gmx.de>:
> On Mon, 2018-01-22 at 20:27 +0800, Wanpeng Li wrote:
>> 2018-01-22 20:08 GMT+08:00 Mike Galbraith <efa...@gmx.de>:
>> > On Mon, 2018-01-22 at 19:47 +0800, Wanpeng Li wrote:
>> >> Hi all,
&g
2018-01-22 21:37 GMT+08:00 Mike Galbraith :
> On Mon, 2018-01-22 at 20:27 +0800, Wanpeng Li wrote:
>> 2018-01-22 20:08 GMT+08:00 Mike Galbraith :
>> > On Mon, 2018-01-22 at 19:47 +0800, Wanpeng Li wrote:
>> >> Hi all,
>> >>
>> >> We can o
2018-01-22 20:53 GMT+08:00 Peter Zijlstra <pet...@infradead.org>:
> On Mon, Jan 22, 2018 at 07:47:45PM +0800, Wanpeng Li wrote:
>> Hi all,
>>
>> We can observe unixbench context switch performance is heavily
>> influenced by cpu topology which is exposed to the gu
2018-01-22 20:53 GMT+08:00 Peter Zijlstra :
> On Mon, Jan 22, 2018 at 07:47:45PM +0800, Wanpeng Li wrote:
>> Hi all,
>>
>> We can observe unixbench context switch performance is heavily
>> influenced by cpu topology which is exposed to the guest. the score is
>&g
2018-01-22 20:08 GMT+08:00 Mike Galbraith <efa...@gmx.de>:
> On Mon, 2018-01-22 at 19:47 +0800, Wanpeng Li wrote:
>> Hi all,
>>
>> We can observe unixbench context switch performance is heavily
>> influenced by cpu topology which is exposed to the guest. the
2018-01-22 20:08 GMT+08:00 Mike Galbraith :
> On Mon, 2018-01-22 at 19:47 +0800, Wanpeng Li wrote:
>> Hi all,
>>
>> We can observe unixbench context switch performance is heavily
>> influenced by cpu topology which is exposed to the guest. the score is
>> pos
,
Wanpeng Li
,
Wanpeng Li
2018-01-19 17:01 GMT+08:00 Wanpeng Li <kernel...@gmail.com>:
> 2018-01-19 16:18 GMT+08:00 Eric Biggers <ebigge...@gmail.com>:
>> From: Eric Biggers <ebigg...@google.com>
>>
>> Memslots must not overlap in guest physical memory, since otherwise some
>> g
2018-01-19 17:01 GMT+08:00 Wanpeng Li :
> 2018-01-19 16:18 GMT+08:00 Eric Biggers :
>> From: Eric Biggers
>>
>> Memslots must not overlap in guest physical memory, since otherwise some
>> guest physical addresses will not uniquely map to a memslot.
VM_SET_TSS_ADDR, 0);
> ioctl(cpu, KVM_RUN, 0);
> ioctl(vm, KVM_SET_USER_MEMORY_REGION, );
> }
>
> Reported-by: syzbot <syzkal...@googlegroups.com>
> Fixes: e0d62c7f4860 ("KVM: Add kernel-internal memory slots")
> Cc: <sta...@vger.kernel
N, 0);
> ioctl(vm, KVM_SET_USER_MEMORY_REGION, );
> }
>
> Reported-by: syzbot
> Fixes: e0d62c7f4860 ("KVM: Add kernel-internal memory slots")
> Cc: # v2.6.25+
> Signed-off-by: Eric Biggers
Please refer to this one. https://patchwork.kernel.org/patch/96
ad of
> doing VMWRITE/VMREAD instructions. Tests show that this speeds up
> tight CPUID loop almost 3 times:
>
> Before:
> ./cpuid_tight
> 20459
>
> After:
> ./cpuid_tight
> 7698
Maybe you can apply a similar idea to kvm nested on kvm.
Regards,
Wanpeng Li
>
> ch
MREAD instructions. Tests show that this speeds up
> tight CPUID loop almost 3 times:
>
> Before:
> ./cpuid_tight
> 20459
>
> After:
> ./cpuid_tight
> 7698
Maybe you can apply a similar idea to kvm nested on kvm.
Regards,
Wanpeng Li
>
> checkpatch.pl errors/warnin
R_IA32_PRED_CMD, PRED_CMD_IBPB);
> }
Intel guys told us the recycle is about the address of vmcs, not the
content. Could you explain more why it matters?
Regards,
Wanpeng Li
BPB);
> }
Intel guys told us the recycle is about the address of vmcs, not the
content. Could you explain more why it matters?
Regards,
Wanpeng Li
48. They expose only 0x49.
>>
>> That is only the IPBP is needed on AMD? (I haven't actually seen any official
>> docs from AMD).
>
> AMD is not exposing 0x48 yet, but they plan to based on my information
> from a few weeks ago.
Haha, interesting, they announce officially there is no issue for
variant 2. http://www.amd.com/en/corporate/speculative-execution
Regards,
Wanpeng Li
nly 0x49.
>>
>> That is only the IPBP is needed on AMD? (I haven't actually seen any official
>> docs from AMD).
>
> AMD is not exposing 0x48 yet, but they plan to based on my information
> from a few weeks ago.
Haha, interesting, they announce officially there is no issue for
variant 2. http://www.amd.com/en/corporate/speculative-execution
Regards,
Wanpeng Li
2018-01-02 7:01 GMT+08:00 Paolo Bonzini <pbonz...@redhat.com>:
> On 01/01/2018 10:36, Paolo Bonzini wrote:
>> On 28/12/2017 09:39, Wanpeng Li wrote:
>>> 2017-12-27 22:28 GMT+08:00 Paolo Bonzini <pbonz...@redhat.com>:
>>>> On 25/12/2017 11:08, Wanpeng Li w
2018-01-02 7:01 GMT+08:00 Paolo Bonzini :
> On 01/01/2018 10:36, Paolo Bonzini wrote:
>> On 28/12/2017 09:39, Wanpeng Li wrote:
>>> 2017-12-27 22:28 GMT+08:00 Paolo Bonzini :
>>>> On 25/12/2017 11:08, Wanpeng Li wrote:
>>>>>> I observe L1
2017-12-31 16:08 GMT+08:00 Paolo Bonzini <pbonz...@redhat.com>:
> On 25/12/2017 04:03, Wanpeng Li wrote:
>> 2017-12-21 20:43 GMT+08:00 Paolo Bonzini <pbonz...@redhat.com>:
>>> VMCS12 fields that are not handled through shadow VMCS are rarely
>>> written,
2017-12-31 16:08 GMT+08:00 Paolo Bonzini :
> On 25/12/2017 04:03, Wanpeng Li wrote:
>> 2017-12-21 20:43 GMT+08:00 Paolo Bonzini :
>>> VMCS12 fields that are not handled through shadow VMCS are rarely
>>> written, and thus they are also almost constant in the vmcs02
2017-12-27 22:28 GMT+08:00 Paolo Bonzini <pbonz...@redhat.com>:
> On 25/12/2017 11:08, Wanpeng Li wrote:
>>> I observe L1(latest kvm/queue) panic and L0(latest kvm/queue)
>>> calltrace, I'm not sure whether it is caused by this patchset.
>> It can be reproduced s
2017-12-27 22:28 GMT+08:00 Paolo Bonzini :
> On 25/12/2017 11:08, Wanpeng Li wrote:
>>> I observe L1(latest kvm/queue) panic and L0(latest kvm/queue)
>>> calltrace, I'm not sure whether it is caused by this patchset.
>> It can be reproduced steadily by running kvm-uni
2017-12-27 17:54 GMT+08:00 Paolo Bonzini <pbonz...@redhat.com>:
> On 25/12/2017 04:09, Wanpeng Li wrote:
>> 2017-12-21 20:43 GMT+08:00 Paolo Bonzini <pbonz...@redhat.com>:
>>> These fields are also simple copies of the data in the vmcs12 struct.
>>> For so
2017-12-27 17:54 GMT+08:00 Paolo Bonzini :
> On 25/12/2017 04:09, Wanpeng Li wrote:
>> 2017-12-21 20:43 GMT+08:00 Paolo Bonzini :
>>> These fields are also simple copies of the data in the vmcs12 struct.
>>> For some of them, prepare_vmcs02 was skipping the copy wh
scm/virt/kvm/kvm.git/commit/?h=queue=ed3b37ac63a060bdc184d126c0655c1af8b6de62
There is a fix in kvm/queue.
Regards,
Wanpeng Li
>
> WARNING: CPU: 0 PID: 3356 at arch/x86/kernel/traps.c:801
> cond_local_irq_disable arch/x86/kernel/traps.c:86 [inline]
> WARNING: CPU: 0 PID: 3356 at arch/x86/kernel/tr
Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers
>
https://git.kernel.org/pub/scm/virt/kvm/kvm.git/commit/?h=queue=ed3b37ac63a060bdc184d126c0655c1af8b6de62
There is a fix in k
2017-12-25 18:07 GMT+08:00 Wanpeng Li <kernel...@gmail.com>:
> 2017-12-21 20:43 GMT+08:00 Paolo Bonzini <pbonz...@redhat.com>:
>> That's about 800-1000 clock cycles more that can be easily peeled, by
>> saving about 60 VMWRITEs on every exit.
>>
>>
2017-12-25 18:07 GMT+08:00 Wanpeng Li :
> 2017-12-21 20:43 GMT+08:00 Paolo Bonzini :
>> That's about 800-1000 clock cycles more that can be easily peeled, by
>> saving about 60 VMWRITEs on every exit.
>>
>> My numbers so far have been collected on a Haswell system vs
5 74 1b
45 31 c0 31 c9 31 f6 ba 10 00 00 00 e8 2d 0e f8 ff 85 c0 0f 94 c0 0f
b6 c0 5d c3 <0f> ff eb e1 0f 1f 44 00 00 66 2e 0f 1f 84 00 00 00 00 00
0f 1f
[ 149.014080] ---[ end trace 53c0bffb9d8f6939 ]---
Regards,
Wanpeng Li
31 f6 ba 10 00 00 00 e8 2d 0e f8 ff 85 c0 0f 94 c0 0f
b6 c0 5d c3 <0f> ff eb e1 0f 1f 44 00 00 66 2e 0f 1f 84 00 00 00 00 00
0f 1f
[ 149.014080] ---[ end trace 53c0bffb9d8f6939 ]---
Regards,
Wanpeng Li
t;irr) ||
> (!edge && entry.fields.remote_irr)) {
> ret = 0;
> goto out;
> }
>
> According to RTC spec, after RTC injects a High level irq, OS will read CMOS's
I think it is falling edge and active low.
Regards,
amp;& entry.fields.remote_irr)) {
> ret = 0;
> goto out;
> }
>
> According to RTC spec, after RTC injects a High level irq, OS will read CMOS's
I think it is falling edge and active low.
Regards,
Wanpeng Li
> register C
> field exists on the host, because the corresponding execution control
> might be one of the shadowed fields.
Why we don't need to copy them always before the patchset?
Regards,
Wanpeng Li
ost, because the corresponding execution control
> might be one of the shadowed fields.
Why we don't need to copy them always before the patchset?
Regards,
Wanpeng Li
> return kvm_skip_emulated_instruction(vcpu);
> }
>
> + switch (field) {
> +#define SHADOW_FIELD_RW(x) case x:
> +#include "vmx_shadow_fields.h"
What's will happen here if enable_shadow_vmcs == false?
Regards,
Wanpeng Li
> +
emulated_instruction(vcpu);
> }
>
> + switch (field) {
> +#define SHADOW_FIELD_RW(x) case x:
> +#include "vmx_shadow_fields.h"
What's will happen here if enable_shadow_vmcs == false?
Regards,
Wanpeng Li
> + /*
> +
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers
>
>
I will have a look again, you continue to run
nsole output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers
>
>
I will have a look again, you continue to run it in kvm guest, right?
Regards,
Wanpeng Li
> kvm: KVM_SET_TSS_ADDR need
ock results omitted. Smaller - better.
Could you test on a x86 box? I see a lot of calltraces on my haswell
client host, there is no calltrace in the guest, however, I can still
observe "Invalid parameters" warning when insmod this module. In
addition, the x86 box fails to boot when ipi_benchmark is buildin.
Regards,
Wanpeng Li
etter.
Could you test on a x86 box? I see a lot of calltraces on my haswell
client host, there is no calltrace in the guest, however, I can still
observe "Invalid parameters" warning when insmod this module. In
addition, the x86 box fails to boot when ipi_benchmark is buildin.
Regards,
Wanpeng Li
= gpa;
> __entry->val = 0;
> if (val)
> - memcpy(&__entry->val, val, min(8, len));
> + memcpy(&__entry->val, val,
> + min_t(u32, sizeof(__entry->val), len));
> ),
>
> TP_printk("mmio %s len %u gpa 0x%llx val 0x%llx",
Thanks Paolo. :)
Regards,
Wanpeng Li
l)
> - memcpy(&__entry->val, val, min(8, len));
> + memcpy(&__entry->val, val,
> + min_t(u32, sizeof(__entry->val), len));
> ),
>
> TP_printk("mmio %s len %u gpa 0x%llx val 0x%llx",
Thanks Paolo. :)
Regards,
Wanpeng Li
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
>
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers
>
>
I will have a look.
Regards,
Wanpeng Li
> BUG:
nsole output is attached.
>
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers
>
>
I will have a look.
Regards,
Wanpeng Li
> BUG: unable to handle kernel NULL pointer dereference at 0010
> IP: irq_bypass_regi
2017-12-15 19:06 GMT+08:00 Marc Zyngier <marc.zyng...@arm.com>:
> On 15/12/17 01:40, Wanpeng Li wrote:
>> From: Wanpeng Li <wanpeng...@hotmail.com>
>>
>> Reported by syzkaller:
>>
>> BUG: KASAN: stack-out-of-bounds in write_mmio+0x11e/0x270 [kvm]
2017-12-15 19:06 GMT+08:00 Marc Zyngier :
> On 15/12/17 01:40, Wanpeng Li wrote:
>> From: Wanpeng Li
>>
>> Reported by syzkaller:
>>
>> BUG: KASAN: stack-out-of-bounds in write_mmio+0x11e/0x270 [kvm]
>> Read of size 8 at addr 8803259df7f8 by tas
gt; +kvm maintainers, you can see full thread here:
>> https://groups.google.com/forum/#!topic/syzkaller-bugs/_oveOKGm3jw
I didn't see any issue after running the test.
Regards,
Wanpeng Li
e full thread here:
>> https://groups.google.com/forum/#!topic/syzkaller-bugs/_oveOKGm3jw
I didn't see any issue after running the test.
Regards,
Wanpeng Li
ted=1
>> kvm-intel.unrestricted_guest=1 kvm-intel.ept=1
>> kvm-intel.flexpriority=1 kvm-intel.vpid=1
>> kvm-intel.emulate_invalid_guest_state=1 kvm-intel.eptad=1
>> kvm-intel.enable_shadow_vmcs=1 kvm-intel.pml=1
>> kvm-intel.enable_apicv=1 console=ttyS0 root=/dev/sda
>> earlyprintk=serial slub_debug=UZ vsyscall=native rodata=n oops=panic
>> panic_on_warn=1 panic=86400
>> [0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating
>> point registers'
>> [0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
>> [0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
>> [0.00] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256
>> [0.00] x86/fpu: Enabled xstate features 0x7, context size is
>> 832 bytes, using 'standard' format.
>> [0.00] e820: BIOS-provided physical RAM map:
>> ...
>
>
> Well, the crash was minimized down to:
>
> // autogenerated by syzkaller (http://github.com/google/syzkaller)
> #define _GNU_SOURCE
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
>
> int main()
> {
> int fd = open("/dev/kvm", 0x80102ul);
> int vm = ioctl(fd, KVM_CREATE_VM, 0);
> int cpu = ioctl(vm, KVM_CREATE_VCPU, 4);
> ioctl(cpu, KVM_RUN, 0);
> return 0;
> }
>
> And, yes, this in fact triggers instant reboot of kernel (running in qemu).
> Am I missing something here?
>
> +kvm maintainers, you can see full thread here:
> https://groups.google.com/forum/#!topic/syzkaller-bugs/_oveOKGm3jw
I will have a try.
Regards,
Wanpeng Li
nable_shadow_vmcs=1 kvm-intel.pml=1
>> kvm-intel.enable_apicv=1 console=ttyS0 root=/dev/sda
>> earlyprintk=serial slub_debug=UZ vsyscall=native rodata=n oops=panic
>> panic_on_warn=1 panic=86400
>> [0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating
>> point registers'
>> [0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
>> [0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
>> [0.00] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256
>> [0.00] x86/fpu: Enabled xstate features 0x7, context size is
>> 832 bytes, using 'standard' format.
>> [0.00] e820: BIOS-provided physical RAM map:
>> ...
>
>
> Well, the crash was minimized down to:
>
> // autogenerated by syzkaller (http://github.com/google/syzkaller)
> #define _GNU_SOURCE
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
>
> int main()
> {
> int fd = open("/dev/kvm", 0x80102ul);
> int vm = ioctl(fd, KVM_CREATE_VM, 0);
> int cpu = ioctl(vm, KVM_CREATE_VCPU, 4);
> ioctl(cpu, KVM_RUN, 0);
> return 0;
> }
>
> And, yes, this in fact triggers instant reboot of kernel (running in qemu).
> Am I missing something here?
>
> +kvm maintainers, you can see full thread here:
> https://groups.google.com/forum/#!topic/syzkaller-bugs/_oveOKGm3jw
I will have a try.
Regards,
Wanpeng Li
(though I've not confirmed).
Yeah, fix it in v4, https://lkml.org/lkml/2017/12/14/954 however, I
don't have an ARM environment to compile it though the change is very
simple.
Regards,
Wanpeng Li
Yeah, fix it in v4, https://lkml.org/lkml/2017/12/14/954 however, I
don't have an ARM environment to compile it though the change is very
simple.
Regards,
Wanpeng Li
901 - 1000 of 5240 matches
Mail list logo
