Re: [PATCH 3/4] KVM: async_pf: Force a nested vmexit if the injected #PF is async_pf

2017-06-14 21:02+0800, Wanpeng Li: > 2017-06-14 20:52 GMT+08:00 Radim Krčmář : > > 2017-06-14 09:07+0800, Wanpeng Li: > >> 2017-06-14 2:55 GMT+08:00 Radim Krčmář : > >> > Using vcpu->arch.cr2 is suspicious as VMX doesn't update CR2 on VM > >> > exits

Re: [PATCH 3/4] KVM: async_pf: Force a nested vmexit if the injected #PF is async_pf

2017-06-14 09:07+0800, Wanpeng Li: > 2017-06-14 2:55 GMT+08:00 Radim Krčmář <rkrc...@redhat.com>: > > Using vcpu->arch.cr2 is suspicious as VMX doesn't update CR2 on VM > > exits; isn't this going to change the CR2 visible in L2 guest after a > > nested VM en

Re: [PATCH 3/4] KVM: async_pf: Force a nested vmexit if the injected #PF is async_pf

2017-06-14 09:07+0800, Wanpeng Li: > 2017-06-14 2:55 GMT+08:00 Radim Krčmář : > > Using vcpu->arch.cr2 is suspicious as VMX doesn't update CR2 on VM > > exits; isn't this going to change the CR2 visible in L2 guest after a > > nested VM entry? > > Sorry, I don't

Re: [PATCH 3/4] KVM: async_pf: Force a nested vmexit if the injected #PF is async_pf

sted_vmx_check_exception() if the injected #PF > is async page fault. > > Cc: Paolo Bonzini <pbonz...@redhat.com> > Cc: Radim Krčmář <rkrc...@redhat.com> > Signed-off-by: Wanpeng Li <wanpeng...@hotmail.com> > --- > diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c

Re: [PATCH 3/4] KVM: async_pf: Force a nested vmexit if the injected #PF is async_pf

ed #PF > is async page fault. > > Cc: Paolo Bonzini > Cc: Radim Krčmář > Signed-off-by: Wanpeng Li > --- > diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c > @@ -2422,13 +2422,28 @@ static void skip_emulated_instruction(struct kvm_vcpu > *vcpu) > static int

Re: [PATCH 4/4] KVM: async_pf: Let host know whether the guest support delivery async_pf as #PF vmexit

est mode. > > Cc: Paolo Bonzini <pbonz...@redhat.com> > Cc: Radim Krčmář <rkrc...@redhat.com> > Signed-off-by: Wanpeng Li <wanpeng...@hotmail.com> > --- I think KVM (L1) should also do something like diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c index dd2

Re: [PATCH 4/4] KVM: async_pf: Let host know whether the guest support delivery async_pf as #PF vmexit

2017-06-12 23:08-0700, Wanpeng Li: > From: Wanpeng Li > > Adds another flag bit (bit 2) to MSR_KVM_ASYNC_PF_EN. If bit 2 is 1, async > page faults are delivered to L1 as #PF vmexits; if bit 2 is 0, > kvm_can_do_async_pf > returns 0 if in guest mode. > > Cc: Paolo Bon

Re: [PATCH v2] KVM: nVMX: Fix exception injection

2017-06-05 14:26+0200, Paolo Bonzini: > On 05/06/2017 14:19, Wanpeng Li wrote: > > From: Wanpeng Li > > This patch fixes it by confirming to inject exception to the guest when the > > exit > > reason in vmcs02 is exception. > > I think the final part of the commit

Re: [PATCH v2] KVM: nVMX: Fix exception injection

2017-06-05 14:26+0200, Paolo Bonzini: > On 05/06/2017 14:19, Wanpeng Li wrote: > > From: Wanpeng Li > > This patch fixes it by confirming to inject exception to the guest when the > > exit > > reason in vmcs02 is exception. > > I think the final part of the commit message needs to be

Re: [PATCH] KVM: SVM: ignore type when setting segment registers

2017-05-30 15:24+0200, Gioh Kim: > This patch is based on linux-next v4.12.0-rc3. (I'd omit this.) > Signed-off-by: Gioh Kim <gi-oh@profitbricks.com> > --- Reviewed-by: Radim Krčmář <rkrc...@redhat.com>

Re: [PATCH] KVM: SVM: ignore type when setting segment registers

2017-05-30 15:24+0200, Gioh Kim: > This patch is based on linux-next v4.12.0-rc3. (I'd omit this.) > Signed-off-by: Gioh Kim > --- Reviewed-by: Radim Krčmář

Re: [PATCH v4] KVM: x86: avoid large stack allocations in em_fxrstor

2017-05-30 12:15+0200, Paolo Bonzini: > On 30/05/2017 00:48, Nick Desaulniers wrote: >> diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c >> @@ -3985,57 +3985,45 @@ static int em_fxsave(struct x86_emulate_ctxt *ctxt) >> static int em_fxrstor(struct x86_emulate_ctxt *ctxt) >> { >>

Re: [PATCH v4] KVM: x86: avoid large stack allocations in em_fxrstor

2017-05-30 12:15+0200, Paolo Bonzini: > On 30/05/2017 00:48, Nick Desaulniers wrote: >> diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c >> @@ -3985,57 +3985,45 @@ static int em_fxsave(struct x86_emulate_ctxt *ctxt) >> static int em_fxrstor(struct x86_emulate_ctxt *ctxt) >> { >>

Re: [RFC] KVM: SVM: ignore type when setting segment registers

2017-05-29 15:24+0200, Gioh Kim: > Current code sets unusable as 1 if present is 1 and type is 0. > In Long mode, type value in segment descriptor is ignored. > So I think type should be ignored when setting the segment registers, > if type means the descriptor type in the segment descriptor. > >

Re: [RFC] KVM: SVM: ignore type when setting segment registers

2017-05-29 15:24+0200, Gioh Kim: > Current code sets unusable as 1 if present is 1 and type is 0. > In Long mode, type value in segment descriptor is ignored. > So I think type should be ignored when setting the segment registers, > if type means the descriptor type in the segment descriptor. > >

Re: [PATCH] KVM: x86: dynamically allocate large struct in em_fxrstor

2017-05-23 23:24-0700, Nick Desaulniers: > Fixes the warning: > > arch/x86/kvm/emulate.c:4018:12: warning: stack frame size of 1080 bytes in > function > 'em_fxrstor' [-Wframe-larger-than=] > static int em_fxrstor(struct x86_emulate_ctxt *ctxt) >^ > > Found with

Re: [PATCH] KVM: x86: dynamically allocate large struct in em_fxrstor

2017-05-23 23:24-0700, Nick Desaulniers: > Fixes the warning: > > arch/x86/kvm/emulate.c:4018:12: warning: stack frame size of 1080 bytes in > function > 'em_fxrstor' [-Wframe-larger-than=] > static int em_fxrstor(struct x86_emulate_ctxt *ctxt) >^ > > Found with

Re: [GIT PULL] KVM fixes for v4.12-rc2

2017-05-20 12:52+0200, Juergen Gross: > On 20/05/17 00:21, Linus Torvalds wrote: > > So I noticed that my diffstat didn't match either the KVM or the Xen pull. > > > > The *reason* seems to be that both Radim and Juergen have enabled the > > "patience" diff, because if I add "--patience" to the

Re: [GIT PULL] KVM fixes for v4.12-rc2

2017-05-20 12:52+0200, Juergen Gross: > On 20/05/17 00:21, Linus Torvalds wrote: > > So I noticed that my diffstat didn't match either the KVM or the Xen pull. > > > > The *reason* seems to be that both Radim and Juergen have enabled the > > "patience" diff, because if I add "--patience" to the

[GIT PULL] KVM fixes for v4.12-rc2

SPAPR TCE code on non-pseries platforms Radim Krčmář (5): Merge branch 'kvm-ppc-fixes' of git://git.kernel.org/.../paulus/powerpc Merge tag 'kvm-arm-for-v4.12-rc2' of git://git.kernel.org/.../kvmarm/kvmarm KVM: x86: zero base3 of unusable segments KVM: x86/vPMU: fix

[GIT PULL] KVM fixes for v4.12-rc2

SPAPR TCE code on non-pseries platforms Radim Krčmář (5): Merge branch 'kvm-ppc-fixes' of git://git.kernel.org/.../paulus/powerpc Merge tag 'kvm-arm-for-v4.12-rc2' of git://git.kernel.org/.../kvmarm/kvmarm KVM: x86: zero base3 of unusable segments KVM: x86/vPMU: fix

[PATCH v2] KVM: nVMX: fix nested_vmx_check_vmptr failure paths under debugging

uction and use it.") Signed-off-by: Radim Krčmář <rkrc...@redhat.com> --- Second try -- moves a lot of code around to make it less ugly and keep the same behavior as v1, hopefully. arch/x86/kvm/vmx.c | 140 ++--- 1 file changed, 57

[PATCH v2] KVM: nVMX: fix nested_vmx_check_vmptr failure paths under debugging

return status means something else: 0 is ok, 1 is error. This means we would continue executing after a failure. Static checker noticed it because vmptr was not initialized. Reported-by: Dan Carpenter Fixes: 6affcbedcac7 ("KVM: x86: Add kvm_skip_emulated_instruction and use it."

Re: [PATCH v3] KVM: x86: Fix potential preemption when get the current kvmclock timestamp

2017-05-19 05:53+0800, Wanpeng Li: > Ping, Applying for 4.12-rc2, thanks.

Re: [PATCH v3] KVM: x86: Fix potential preemption when get the current kvmclock timestamp

2017-05-19 05:53+0800, Wanpeng Li: > Ping, Applying for 4.12-rc2, thanks.

Re: [PATCH 0/4] KVM: x86: fix bugs reported by Dan Carpenter

2017-05-18 20:52+0200, Paolo Bonzini: > On 18/05/2017 19:37, Radim Krčmář wrote: > > It would be possible to make reproducers for the first three patches, > > but they happen under circumstances too remote from normal use, so I > > didn't test them like that. :) > >

Re: [PATCH 0/4] KVM: x86: fix bugs reported by Dan Carpenter

2017-05-18 20:52+0200, Paolo Bonzini: > On 18/05/2017 19:37, Radim Krčmář wrote: > > It would be possible to make reproducers for the first three patches, > > but they happen under circumstances too remote from normal use, so I > > didn't test them like that. :) > >

[PATCH 3/4] KVM: x86/vPMU: fix undefined shift in intel_pmu_refresh()

6/vPMU: Define kvm_pmu_ops to support vPMU function dispatch") Signed-off-by: Radim Krčmář <rkrc...@redhat.com> --- arch/x86/kvm/pmu_intel.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kvm/pmu_intel.c b/arch/x86/kvm/pmu_intel.c index 9d4a8504a95a..5ab4a3643

[PATCH 3/4] KVM: x86/vPMU: fix undefined shift in intel_pmu_refresh()

ort vPMU function dispatch") Signed-off-by: Radim Krčmář --- arch/x86/kvm/pmu_intel.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kvm/pmu_intel.c b/arch/x86/kvm/pmu_intel.c index 9d4a8504a95a..5ab4a364348e 100644 --- a/arch/x86/kvm/pmu_intel.c +++ b/arch/x86/kv

[PATCH 4/4] KVM: x86: prevent uninitialized variable warning in check_svme()

get_msr() of MSR_EFER is currently always going to succeed, but static checker doesn't see that far. Don't complicate stuff and just use 0 for the fallback -- it means that the feature is not present. Reported-by: Dan Carpenter <dan.carpen...@oracle.com> Signed-off-by: Radim Krčmář

[PATCH 4/4] KVM: x86: prevent uninitialized variable warning in check_svme()

get_msr() of MSR_EFER is currently always going to succeed, but static checker doesn't see that far. Don't complicate stuff and just use 0 for the fallback -- it means that the feature is not present. Reported-by: Dan Carpenter Signed-off-by: Radim Krčmář --- arch/x86/kvm/emulate.c | 2 +- 1

[PATCH 2/4] KVM: x86: zero base3 of unusable segments

t accessors") Signed-off-by: Radim Krčmář <rkrc...@redhat.com> --- arch/x86/kvm/x86.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index b54125b590e8..eed8272dd52e 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -5053,6

[PATCH 1/4] KVM: nVMX: fix nested_vmx_check_vmptr failure paths under debugging

uction and use it.") Signed-off-by: Radim Krčmář <rkrc...@redhat.com> --- TODO: add enum for exit handler return states. --- arch/x86/kvm/vmx.c | 31 ++- 1 file changed, 18 insertions(+), 13 deletions(-) diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx

[PATCH 2/4] KVM: x86: zero base3 of unusable segments

Static checker noticed that base3 could be used uninitialized if the segment was not present (useable). Random stack values probably would not pass VMCS entry checks. Reported-by: Dan Carpenter Fixes: 1aa366163b8b ("KVM: x86 emulator: consolidate segment accessors") Signed-off-by: Ra

[PATCH 1/4] KVM: nVMX: fix nested_vmx_check_vmptr failure paths under debugging

return status means something else: 0 is ok, 1 is error. This means we would continue executing after a failure. Static checker noticed it because vmptr was not initialized. Reported-by: Dan Carpenter Fixes: 6affcbedcac7 ("KVM: x86: Add kvm_skip_emulated_instruction and use it."

[PATCH 0/4] KVM: x86: fix bugs reported by Dan Carpenter

It would be possible to make reproducers for the first three patches, but they happen under circumstances too remote from normal use, so I didn't test them like that. :) Radim Krčmář (4): KVM: nVMX: fix nested_vmx_check_vmptr failure paths under debugging KVM: x86: zero base3 of unusable

[PATCH 0/4] KVM: x86: fix bugs reported by Dan Carpenter

It would be possible to make reproducers for the first three patches, but they happen under circumstances too remote from normal use, so I didn't test them like that. :) Radim Krčmář (4): KVM: nVMX: fix nested_vmx_check_vmptr failure paths under debugging KVM: x86: zero base3 of unusable

[PATCH] KVM: x86: update master clock before computing kvmclock_offset

, which means that the master clock and kernel boot clock will be sufficiently close together. Another solution would be to replace get_kvmclock_ns() with "ktime_get_boot_ns() + ka->kvmclock_offset", which is marginally more accurate, but would break symmetry with KVM_GET_CLOCK. Signed-

[PATCH] KVM: x86: update master clock before computing kvmclock_offset

, which means that the master clock and kernel boot clock will be sufficiently close together. Another solution would be to replace get_kvmclock_ns() with "ktime_get_boot_ns() + ka->kvmclock_offset", which is marginally more accurate, but would break symmetry with KVM_GET_CLOCK. Signed-

Re: [PATCH] KVM: x86: lower default for halt_poll_ns

2017-05-16 18:58+0200, Paolo Bonzini: > On 18/04/2017 12:41, Paolo Bonzini wrote: >> In some fio benchmarks, halt_poll_ns=40 caused CPU utilization to >> increase heavily even in cases where the performance improvement was >> small. In particular, bandwidth divided by CPU usage was as much as

Re: [PATCH] KVM: x86: lower default for halt_poll_ns

2017-05-16 18:58+0200, Paolo Bonzini: > On 18/04/2017 12:41, Paolo Bonzini wrote: >> In some fio benchmarks, halt_poll_ns=40 caused CPU utilization to >> increase heavily even in cases where the performance improvement was >> small. In particular, bandwidth divided by CPU usage was as much as

Re: [PATCH 0/2] KVM: nVMX: nested EPT fixes

2017-05-11 13:23+0200, Paolo Bonzini: > These two patches fix a couple corner cases identified by the new > tests in vmx.flat. See the individual patches for more information. > > Paolo > > Paolo Bonzini (2): > KVM: nVMX: fix EPT permissions as reported in exit qualification > KVM: nVMX:

Re: [PATCH 0/2] KVM: nVMX: nested EPT fixes

2017-05-11 13:23+0200, Paolo Bonzini: > These two patches fix a couple corner cases identified by the new > tests in vmx.flat. See the individual patches for more information. > > Paolo > > Paolo Bonzini (2): > KVM: nVMX: fix EPT permissions as reported in exit qualification > KVM: nVMX:

Re: [PATCH 3/4] KVM: x86: drop bogus MWAIT check

2017-05-04 21:29+0300, Michael S. Tsirkin: > On Thu, May 04, 2017 at 04:33:28PM +0200, Radim Krčmář wrote: >> 2017-05-04 12:58+0200, Paolo Bonzini: >> > On 03/05/2017 21:37, Radim Krčmář wrote: >> >> The guest can call MWAIT with ECX = 0 even if we enforce &g

Re: [PATCH 3/4] KVM: x86: drop bogus MWAIT check

2017-05-04 21:29+0300, Michael S. Tsirkin: > On Thu, May 04, 2017 at 04:33:28PM +0200, Radim Krčmář wrote: >> 2017-05-04 12:58+0200, Paolo Bonzini: >> > On 03/05/2017 21:37, Radim Krčmář wrote: >> >> The guest can call MWAIT with ECX = 0 even if we enforce &g

Re: [PATCH 0/4] KVM: x86: kvm_mwait_in_guest() cleanup and fixes

2017-05-04 13:56-0400, Gabriel L. Somlo: > If I wanted to test this (e.g. with OS X 10.8 guests on several of my older > Mac boxes running Fedora), which git repo would you have me use? (The series > won't apply directly on top of git://git.kernel.org/pub/scm/virt/kvm/kvm.git). The queue branch

Re: [PATCH 0/4] KVM: x86: kvm_mwait_in_guest() cleanup and fixes

2017-05-04 13:56-0400, Gabriel L. Somlo: > If I wanted to test this (e.g. with OS X 10.8 guests on several of my older > Mac boxes running Fedora), which git repo would you have me use? (The series > won't apply directly on top of git://git.kernel.org/pub/scm/virt/kvm/kvm.git). The queue branch

Re: [PATCH 3/4] KVM: x86: drop bogus MWAIT check

2017-05-04 12:58+0200, Paolo Bonzini: > On 03/05/2017 21:37, Radim Krčmář wrote: >> The guest can call MWAIT with ECX = 0 even if we enforce >> CPUID5_ECX_INTERRUPT_BREAK; the call would have the exactly the same >> effect as if the host didn't have CPUID5_ECX_INTERRUPT_BR

Re: [PATCH 3/4] KVM: x86: drop bogus MWAIT check

2017-05-04 12:58+0200, Paolo Bonzini: > On 03/05/2017 21:37, Radim Krčmář wrote: >> The guest can call MWAIT with ECX = 0 even if we enforce >> CPUID5_ECX_INTERRUPT_BREAK; the call would have the exactly the same >> effect as if the host didn't have CPUID5_ECX_INTERRUPT_BR

Re: [PATCH 1/4] KVM: svm: prevent MWAIT in guest with erratum 400

2017-05-03 22:11+0200, Borislav Petkov: > On Wed, May 03, 2017 at 09:37:30PM +0200, Radim Krčmář wrote: >> The host might miss APIC timer interrupts if the guest enters a specific >> C-state. Quoting the erratum: >> >> 400 APIC Timer Interrupt Does Not

Re: [PATCH 1/4] KVM: svm: prevent MWAIT in guest with erratum 400

2017-05-03 22:11+0200, Borislav Petkov: > On Wed, May 03, 2017 at 09:37:30PM +0200, Radim Krčmář wrote: >> The host might miss APIC timer interrupts if the guest enters a specific >> C-state. Quoting the erratum: >> >> 400 APIC Timer Interrupt Does Not

[PATCH 4/4] KVM: x86: simplify kvm_mwait_in_guest()

If Intel/AMD implements MWAIT, we expect that it works well and only reject known bugs; no reason to do it the other way around for minor vendors. (Not that they are relevant ATM.) This allows further simplification of kvm_mwait_in_guest(). Signed-off-by: Radim Krčmář <rkrc...@redhat.

[PATCH 3/4] KVM: x86: drop bogus MWAIT check

CPUID5_ECX_INTERRUPT_BREAK and the bug is elsewhere. Signed-off-by: Radim Krčmář <rkrc...@redhat.com> --- arch/x86/kvm/x86.h | 23 +-- 1 file changed, 1 insertion(+), 22 deletions(-) diff --git a/arch/x86/kvm/x86.h b/arch/x86/kvm/x86.h index 63d5fb65ea30..8ea4e80c24d1

[PATCH 4/4] KVM: x86: simplify kvm_mwait_in_guest()

If Intel/AMD implements MWAIT, we expect that it works well and only reject known bugs; no reason to do it the other way around for minor vendors. (Not that they are relevant ATM.) This allows further simplification of kvm_mwait_in_guest(). Signed-off-by: Radim Krčmář --- arch/x86/kvm/x86.h

[PATCH 3/4] KVM: x86: drop bogus MWAIT check

CPUID5_ECX_INTERRUPT_BREAK and the bug is elsewhere. Signed-off-by: Radim Krčmář --- arch/x86/kvm/x86.h | 23 +-- 1 file changed, 1 insertion(+), 22 deletions(-) diff --git a/arch/x86/kvm/x86.h b/arch/x86/kvm/x86.h index 63d5fb65ea30..8ea4e80c24d1 100644 --- a/arch/x86/kvm/x86.h

[PATCH 2/4] KVM: x86: prevent MWAIT in guest with buggy MONITOR

The bug prevents MWAIT from waking up after a write to the monitored cache line. KVM might emulate a CPU model that shouldn't have the bug, so the guest would not employ a workaround and possibly miss wakeups. Better to avoid the situation. Signed-off-by: Radim Krčmář <rkrc...@redhat.

[PATCH 2/4] KVM: x86: prevent MWAIT in guest with buggy MONITOR

The bug prevents MWAIT from waking up after a write to the monitored cache line. KVM might emulate a CPU model that shouldn't have the bug, so the guest would not employ a workaround and possibly miss wakeups. Better to avoid the situation. Signed-off-by: Radim Krčmář --- arch/x86/kvm/x86.h | 3

[PATCH 0/4] KVM: x86: kvm_mwait_in_guest() cleanup and fixes

that sacrificed it for "greater good". Radim Krčmář (4): KVM: svm: prevent MWAIT in guest with erratum 400 KVM: x86: prevent MWAIT in guest with buggy MONITOR KVM: x86: drop bogus MWAIT check KVM: x86: simplify kvm_mwait_in_guest() arch/x86/kvm/x86.h | 33 +++---

[PATCH 1/4] KVM: svm: prevent MWAIT in guest with erratum 400

this effect significant. Signed-off-by: Radim Krčmář <rkrc...@redhat.com> --- arch/x86/kvm/x86.h | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/x86/kvm/x86.h b/arch/x86/kvm/x86.h index 612067074905..3ed7dd8737ab 100644 --- a/arch/x86/kvm/x86.h +++ b/arch/x86/kvm

[PATCH 0/4] KVM: x86: kvm_mwait_in_guest() cleanup and fixes

that sacrificed it for "greater good". Radim Krčmář (4): KVM: svm: prevent MWAIT in guest with erratum 400 KVM: x86: prevent MWAIT in guest with buggy MONITOR KVM: x86: drop bogus MWAIT check KVM: x86: simplify kvm_mwait_in_guest() arch/x86/kvm/x86.h | 33 +++---

[PATCH 1/4] KVM: svm: prevent MWAIT in guest with erratum 400

this effect significant. Signed-off-by: Radim Krčmář --- arch/x86/kvm/x86.h | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/x86/kvm/x86.h b/arch/x86/kvm/x86.h index 612067074905..3ed7dd8737ab 100644 --- a/arch/x86/kvm/x86.h +++ b/arch/x86/kvm/x86.h @@ -223,8 +223,7 @@ static

[PATCH v3] KVM: remove #ifndef CONFIG_S390 around kvm_vcpu_wake_up

The #ifndef was protecting a missing halt_wakeup stat, but that is no longer necessary. The #ifndef around kvm_vcpu_kick is still necessary as s390 does not export smp_send_reschedule. Signed-off-by: Radim Krčmář <rkrc...@redhat.com> --- v3: kept kvm_vcpu_kick() under the #ifndef and c

[PATCH v3] KVM: remove #ifndef CONFIG_S390 around kvm_vcpu_wake_up

The #ifndef was protecting a missing halt_wakeup stat, but that is no longer necessary. The #ifndef around kvm_vcpu_kick is still necessary as s390 does not export smp_send_reschedule. Signed-off-by: Radim Krčmář --- v3: kept kvm_vcpu_kick() under the #ifndef and compile tested with kvm

Re: [PATCH v2 3/9] KVM: remove #ifndef CONFIG_S390 around kvm_vcpu_wake_up

2017-04-26 22:32+0200, Radim Krčmář: > The #ifndef was protecting a missing halt_wakeup stat, but that is no > longer necessary. It was also protecting smp_send_reschedule() in kvm_vcpu_kick() and I didn't include Christian's patch that exported it and also missed the warning. Going to s

Re: [PATCH v2 3/9] KVM: remove #ifndef CONFIG_S390 around kvm_vcpu_wake_up

2017-04-26 22:32+0200, Radim Krčmář: > The #ifndef was protecting a missing halt_wakeup stat, but that is no > longer necessary. It was also protecting smp_send_reschedule() in kvm_vcpu_kick() and I didn't include Christian's patch that exported it and also missed the warning. Going to s

Re: [PATCH] x86: kvm: Avoid guest page table walk when gpa_available is set

2017-04-25 17:02-0500, Brijesh Singh: > > > I also wanted to avoid adding yet another variable but we can't depend on > > > cr2 parameters passed into x86_emulate_instruction(). > > > > > > The x86_emulate_instruction() function is called from two places: > > > > > > 1) handling the page-fault.

Re: [PATCH] x86: kvm: Avoid guest page table walk when gpa_available is set

2017-04-25 17:02-0500, Brijesh Singh: > > > I also wanted to avoid adding yet another variable but we can't depend on > > > cr2 parameters passed into x86_emulate_instruction(). > > > > > > The x86_emulate_instruction() function is called from two places: > > > > > > 1) handling the page-fault.

[PATCH v2 3/9] KVM: remove #ifndef CONFIG_S390 around kvm_vcpu_wake_up

The #ifndef was protecting a missing halt_wakeup stat, but that is no longer necessary. Acked-by: Christian Borntraeger <borntrae...@de.ibm.com> Signed-off-by: Radim Krčmář <rkrc...@redhat.com> --- virt/kvm/kvm_main.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/virt/kvm/

[PATCH v2 3/9] KVM: remove #ifndef CONFIG_S390 around kvm_vcpu_wake_up

The #ifndef was protecting a missing halt_wakeup stat, but that is no longer necessary. Acked-by: Christian Borntraeger Signed-off-by: Radim Krčmář --- virt/kvm/kvm_main.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index 357e67cba32e

[PATCH v2 7/9] KVM: improve arch vcpu request defining

From: Andrew Jones Marc Zyngier suggested that we define the arch specific VCPU request base, rather than requiring each arch to remember to start from 8. That suggestion, along with Radim Krčmář's recent VCPU request flag addition, snowballed into defining something of an

[PATCH v2 6/9] KVM: add explicit barrier to kvm_vcpu_kick

From: Andrew Jones kvm_vcpu_kick() must issue a general memory barrier prior to reading vcpu->mode in order to ensure correctness of the mutual-exclusion memory barrier pattern used with vcpu->requests. While the cmpxchg called from kvm_vcpu_kick(): kvm_vcpu_kick

[PATCH v2 7/9] KVM: improve arch vcpu request defining

From: Andrew Jones Marc Zyngier suggested that we define the arch specific VCPU request base, rather than requiring each arch to remember to start from 8. That suggestion, along with Radim Krčmář's recent VCPU request flag addition, snowballed into defining something of an arch VCPU request

[PATCH v2 6/9] KVM: add explicit barrier to kvm_vcpu_kick

From: Andrew Jones kvm_vcpu_kick() must issue a general memory barrier prior to reading vcpu->mode in order to ensure correctness of the mutual-exclusion memory barrier pattern used with vcpu->requests. While the cmpxchg called from kvm_vcpu_kick(): kvm_vcpu_kick kvm_arch_vcpu_should_kick

[PATCH v2 4/9] KVM: mark requests that do not need a wakeup

mbly. Signed-off-by: Radim Krčmář <rkrc...@redhat.com> --- v2: use GENMASK [Marc] --- arch/arm/include/asm/kvm_host.h | 2 +- arch/arm64/include/asm/kvm_host.h | 2 +- arch/x86/include/asm/kvm_host.h | 6 +++--- include/linux/kvm_host.h | 12 +++- 4 files changed, 12

[PATCH v2 4/9] KVM: mark requests that do not need a wakeup

mbly. Signed-off-by: Radim Krčmář --- v2: use GENMASK [Marc] --- arch/arm/include/asm/kvm_host.h | 2 +- arch/arm64/include/asm/kvm_host.h | 2 +- arch/x86/include/asm/kvm_host.h | 6 +++--- include/linux/kvm_host.h | 12 +++- 4 files changed, 12 insertions(+), 10 delet

[PATCH v2 9/9] KVM: mark requests that need synchronization

-by: Radim Krčmář <rkrc...@redhat.com> --- v2: replaces [v1 1/6] Ugh, KVM_ARCH_REQ_WAIT_NO_WAKEUP looks a weird ... --- arch/arm/include/asm/kvm_host.h | 2 +- arch/arm64/include/asm/kvm_host.h | 2 +- arch/x86/include/asm/kvm_host.h | 6 +++--- include/linux/kvm_host.h

[PATCH v2 9/9] KVM: mark requests that need synchronization

-by: Radim Krčmář --- v2: replaces [v1 1/6] Ugh, KVM_ARCH_REQ_WAIT_NO_WAKEUP looks a weird ... --- arch/arm/include/asm/kvm_host.h | 2 +- arch/arm64/include/asm/kvm_host.h | 2 +- arch/x86/include/asm/kvm_host.h | 6 +++--- include/linux/kvm_host.h | 8 ++-- virt/kvm

[PATCH v2 5/9] KVM: perform a wake_up in kvm_make_all_cpus_request

this condition after it is merged with kvm_make_request() because we currently don't know which request is being kicked. Signed-off-by: Radim Krčmář <rkrc...@redhat.com> --- virt/kvm/kvm_main.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c

[PATCH v2 5/9] KVM: perform a wake_up in kvm_make_all_cpus_request

this condition after it is merged with kvm_make_request() because we currently don't know which request is being kicked. Signed-off-by: Radim Krčmář --- virt/kvm/kvm_main.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index e5d52b46b531..3772f7dcc72d

[PATCH v2 8/9] KVM: return if kvm_vcpu_wake_up() did wake up the VCPU

No need to kick a VCPU that we have just woken up. Signed-off-by: Radim Krčmář <rkrc...@redhat.com> --- include/linux/kvm_host.h | 2 +- virt/kvm/kvm_main.c | 12 2 files changed, 9 insertions(+), 5 deletions(-) diff --git a/include/linux/kvm_host.h b/include/linux/kvm_

[PATCH v2 8/9] KVM: return if kvm_vcpu_wake_up() did wake up the VCPU

No need to kick a VCPU that we have just woken up. Signed-off-by: Radim Krčmář --- include/linux/kvm_host.h | 2 +- virt/kvm/kvm_main.c | 12 2 files changed, 9 insertions(+), 5 deletions(-) diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h index 955debd82cf2

[PATCH v2 2/9] KVM: x86: always use kvm_make_request instead of set_bit

Reviewed-by: David Hildenbrand <da...@redhat.com> Signed-off-by: Radim Krčmář <rkrc...@redhat.com> --- arch/x86/kvm/x86.c | 10 ++ 1 file changed, 2 insertions(+), 8 deletions(-) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 2de54c20fa9e..0936c3e2e51c 100644 --

[PATCH v2 2/9] KVM: x86: always use kvm_make_request instead of set_bit

Reviewed-by: David Hildenbrand Signed-off-by: Radim Krčmář --- arch/x86/kvm/x86.c | 10 ++ 1 file changed, 2 insertions(+), 8 deletions(-) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 2de54c20fa9e..0936c3e2e51c 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c

[PATCH v2 1/9] KVM: add kvm_{test,clear}_request to replace {test,clear}_bit

rae...@de.ibm.com> Signed-off-by: Radim Krčmář <rkrc...@redhat.com> --- arch/mips/kvm/emulate.c | 2 +- arch/powerpc/kvm/book3s_pr.c | 2 +- arch/powerpc/kvm/book3s_pr_papr.c | 2 +- arch/powerpc/kvm/booke.c | 4 ++-- arch/powerpc/kvm/powerpc.c| 2 +- arch/

[PATCH v2 1/9] KVM: add kvm_{test,clear}_request to replace {test,clear}_bit

-by: Radim Krčmář --- arch/mips/kvm/emulate.c | 2 +- arch/powerpc/kvm/book3s_pr.c | 2 +- arch/powerpc/kvm/book3s_pr_papr.c | 2 +- arch/powerpc/kvm/booke.c | 4 ++-- arch/powerpc/kvm/powerpc.c| 2 +- arch/s390/kvm/kvm-s390.c | 2 +- arch/x86/kvm/vmx.c

[PATCH v2 0/9] KVM: towards maintainable kvm_make_all_cpus_request()

and a simple optimization for wakeups. v1: http://www.spinics.net/lists/kvm/msg147898.html Andrew Jones (2): KVM: add explicit barrier to kvm_vcpu_kick KVM: improve arch vcpu request defining Radim Krčmář (7): KVM: add kvm_{test,clear}_request to replace {test,clear}_bit KVM: x86

[PATCH v2 0/9] KVM: towards maintainable kvm_make_all_cpus_request()

and a simple optimization for wakeups. v1: http://www.spinics.net/lists/kvm/msg147898.html Andrew Jones (2): KVM: add explicit barrier to kvm_vcpu_kick KVM: improve arch vcpu request defining Radim Krčmář (7): KVM: add kvm_{test,clear}_request to replace {test,clear}_bit KVM: x86

Re: kernel/rcu/tree.c:1031 rcu_irq_enter() invoked with irqs enabled!!!!

2017-04-26 16:29+0200, Paolo Bonzini: > On 26/04/2017 16:18, Radim Krčmář wrote: >>> OK, but looking at the stack trace, this has nothing to do with ext4. The >>> problem seems to be in KVM - relevant CCs added. >> The path begins with async_page_fault interrupt gate

Re: kernel/rcu/tree.c:1031 rcu_irq_enter() invoked with irqs enabled!!!!

2017-04-26 16:29+0200, Paolo Bonzini: > On 26/04/2017 16:18, Radim Krčmář wrote: >>> OK, but looking at the stack trace, this has nothing to do with ext4. The >>> problem seems to be in KVM - relevant CCs added. >> The path begins with async_page_fault interrupt gate

Re: kernel/rcu/tree.c:1031 rcu_irq_enter() invoked with irqs enabled!!!!

2017-04-26 09:16+0200, Jan Kara: > On Tue 25-04-17 13:28:41, Paul E. McKenney wrote: > > On Tue, Apr 25, 2017 at 02:13:45PM -0600, Ross Zwisler wrote: > > > I hit this RCU warning while running mkfs.ext4 on a PMEM namespace with > > > an unmodified v4.11-rc8 (passed through kasan_symbolize.py): >

Re: kernel/rcu/tree.c:1031 rcu_irq_enter() invoked with irqs enabled!!!!

2017-04-26 09:16+0200, Jan Kara: > On Tue 25-04-17 13:28:41, Paul E. McKenney wrote: > > On Tue, Apr 25, 2017 at 02:13:45PM -0600, Ross Zwisler wrote: > > > I hit this RCU warning while running mkfs.ext4 on a PMEM namespace with > > > an unmodified v4.11-rc8 (passed through kasan_symbolize.py): >

Re: [PATCH 1/2] kvm: Fix mmu_notifier release race

2017-04-24 11:10+0100, Suzuki K Poulose: > The KVM uses mmu_notifier (wherever available) to keep track > of the changes to the mm of the guest. The guest shadow page > tables are released when the VM exits via mmu_notifier->ops.release(). > There is a rare chance that the mmu_notifier->release

Re: [PATCH 1/2] kvm: Fix mmu_notifier release race

2017-04-24 11:10+0100, Suzuki K Poulose: > The KVM uses mmu_notifier (wherever available) to keep track > of the changes to the mm of the guest. The guest shadow page > tables are released when the VM exits via mmu_notifier->ops.release(). > There is a rare chance that the mmu_notifier->release

Re: [PATCH] x86: kvm: Avoid guest page table walk when gpa_available is set

2017-04-24 17:14-0500, Brijesh Singh: >> >/* GPA available (AMD only) */ >> >bool gpa_available; >> > + gpa_t gpa_val; >> >> Can't we pass this information through function parameters? >> >> (I'd rather avoid intractable variables.) >> > > I also wanted to avoid adding yet another

Re: [PATCH] x86: kvm: Avoid guest page table walk when gpa_available is set

2017-04-24 17:14-0500, Brijesh Singh: >> >/* GPA available (AMD only) */ >> >bool gpa_available; >> > + gpa_t gpa_val; >> >> Can't we pass this information through function parameters? >> >> (I'd rather avoid intractable variables.) >> > > I also wanted to avoid adding yet another

Re: [PATCH] x86: kvm: Avoid guest page table walk when gpa_available is set

2017-04-24 11:52-0400, Brijesh Singh: > On AMD hardware when a guest causes a NFP which requires emulation, > the vcpu->arch.gpa_available flag is set to indicate that cr2 contains > a valid GPA. > > Currently, emulator_read_write_onepage() makes use of gpa_available flag > to avoid a guest page

Re: [PATCH] x86: kvm: Avoid guest page table walk when gpa_available is set

2017-04-24 11:52-0400, Brijesh Singh: > On AMD hardware when a guest causes a NFP which requires emulation, > the vcpu->arch.gpa_available flag is set to indicate that cr2 contains > a valid GPA. > > Currently, emulator_read_write_onepage() makes use of gpa_available flag > to avoid a guest page

Re: [PATCH 3/4] KVM: add KVM_CREATE_VM2 system ioctl

2017-04-24 18:22+0200, Radim Krčmář: > 2017-04-18 16:30+0200, Paolo Bonzini: >> On 18/04/2017 16:16, Paolo Bonzini wrote: >>>> This patch allows userspace to tell how many VCPUs it is going to use, >>>> which can save memory when allocating the kvm->vcpus array

Re: [PATCH 3/4] KVM: add KVM_CREATE_VM2 system ioctl

2017-04-24 18:22+0200, Radim Krčmář: > 2017-04-18 16:30+0200, Paolo Bonzini: >> On 18/04/2017 16:16, Paolo Bonzini wrote: >>>> This patch allows userspace to tell how many VCPUs it is going to use, >>>> which can save memory when allocating the kvm->vcpus array

Re: [PATCH 0/4] KVM: add KVM_CREATE_VM2 to allow dynamic kvm->vcpus array

2017-04-18 14:29+0200, Cornelia Huck: > On Tue, 18 Apr 2017 13:11:55 +0200 > David Hildenbrand <da...@redhat.com> wrote: >> On 13.04.2017 22:19, Radim Krčmář wrote: >> > new KVM_MAX_CONFIGURABLE_VCPUS, probably directly to INT_MAX/KVM_VCPU_ID, >> >

<    2   3   4   5   6   7   8   9   10   11   >