[tip:x86/urgent] x86/hyper-v: Fix definition of HV_MAX_FLUSH_REP_COUNT

Commit-ID: 9cd05ad2910b55238e3c720c99ad896dc538301b Gitweb: https://git.kernel.org/tip/9cd05ad2910b55238e3c720c99ad896dc538301b Author: Lan Tianyu AuthorDate: Mon, 25 Feb 2019 22:31:14 +0800 Committer: Thomas Gleixner CommitDate: Thu, 28 Feb 2019 11:58:29 +0100 x86/hyper-v: Fix

Re: [Resend Patch] KVM/x86: Fix wrong macro references of X86_CR0_PG_BIT and X86_CR4_PAE_BIT in kvm_valid_sregs()

X86_CR0_PG_BIT and X86_CR4_PAE_BIT. This patch is > > to fix it. > > > > Fixes: f29810335965a(KVM/x86: Check input paging mode when cs.l is set) > > Reported-by: Jeremi Piotrowski <jeremi.piotrow...@gmail.com> > > Cc: Paolo Bonzini <pbonz...@redhat.com> > > Cc:

Re: [Resend Patch] KVM/x86: Fix wrong macro references of X86_CR0_PG_BIT and X86_CR4_PAE_BIT in kvm_valid_sregs()

Hi Eric: Great thanks for your review. On Thu, Jan 18, 2018 at 10:39:04AM -0800, Eric Biggers wrote: > On Tue, Jan 16, 2018 at 05:34:07PM +0800, Tianyu Lan wrote: > > kvm_valid_sregs() should use X86_CR0_PG and X86_CR4_PAE to check bit > > status rather than X86_CR0_PG_BIT and

[PATCH V2] KVM/Eventfd: Avoid crash when assign and deassign specific eventfd in parallel.

) to make sure that irqfd has been fully initialized in the assign path. Reported-by: Dmitry Vyukov <dvyu...@google.com> Cc: Paolo Bonzini <pbonz...@redhat.com> Cc: Radim Krčmář <rkrc...@redhat.com> Cc: Dmitry Vyukov <dvyu...@google.com> Signed-off-by: Tianyu Lan <tianyu...

[PATCH V2] KVM/Eventfd: Avoid crash when assign and deassign specific eventfd in parallel.

Syzroot reports crash in kvm_irqfd_assign() is caused by use-after-free. Because kvm_irqfd_assign() and kvm_irqfd_deassign() can't run in parallel for one specific eventfd. When assign path hasn't been finished after irqfd has been added to kvm->irqfds.items list, another thead may deassign the

Re: [PATCH linux-next] KVM: x86: don't forget vcpu_put() in kvm_arch_vcpu_ioctl_set_sregs()

On 2017年12月21日 08:30, Paolo Bonzini wrote: > On 21/12/2017 01:24, Eric Biggers wrote: >> From: Eric Biggers >> >> Due to a bad merge resolution between commit f29810335965 ("KVM/x86: >> Check input paging mode when cs.l is set") and commit b4ef9d4e8cb8 >> ("KVM: Move

Re: [PATCH linux-next] KVM: x86: don't forget vcpu_put() in kvm_arch_vcpu_ioctl_set_sregs()

On 2017年12月21日 08:30, Paolo Bonzini wrote: > On 21/12/2017 01:24, Eric Biggers wrote: >> From: Eric Biggers >> >> Due to a bad merge resolution between commit f29810335965 ("KVM/x86: >> Check input paging mode when cs.l is set") and commit b4ef9d4e8cb8 >> ("KVM: Move vcpu_load to arch-specific

Re: [PATCH] KVM/Eventfd: Avoid crash when assign and deassign same eventfd in parallel.

On 2017年12月19日 18:41, Paolo Bonzini wrote: > On 19/12/2017 07:35, Lan Tianyu wrote: >> On 2017年12月18日 16:50, Paolo Bonzini wrote: >>> On 18/12/2017 09:30, David Hildenbrand wrote: >>>> The ugly thing in kvm_irqfd_assign() is that we access irqfd without >>&g

Re: [PATCH] KVM/Eventfd: Avoid crash when assign and deassign same eventfd in parallel.

On 2017年12月19日 18:41, Paolo Bonzini wrote: > On 19/12/2017 07:35, Lan Tianyu wrote: >> On 2017年12月18日 16:50, Paolo Bonzini wrote: >>> On 18/12/2017 09:30, David Hildenbrand wrote: >>>> The ugly thing in kvm_irqfd_assign() is that we access irqfd without >>&g

Re: [PATCH] KVM/Eventfd: Avoid crash when assign and deassign same eventfd in parallel.

On 2017年12月18日 16:50, Paolo Bonzini wrote: > On 18/12/2017 09:30, David Hildenbrand wrote: >> The ugly thing in kvm_irqfd_assign() is that we access irqfd without >> holding a lock. I think that should rather be fixed than working around >> that issue. (e.g. lock() -> lookup again -> verify still

Re: [PATCH] KVM/Eventfd: Avoid crash when assign and deassign same eventfd in parallel.

On 2017年12月18日 16:50, Paolo Bonzini wrote: > On 18/12/2017 09:30, David Hildenbrand wrote: >> The ugly thing in kvm_irqfd_assign() is that we access irqfd without >> holding a lock. I think that should rather be fixed than working around >> that issue. (e.g. lock() -> lookup again -> verify still

Re: [PATCH] KVM/Eventfd: Avoid crash when assign and deassign same eventfd in parallel.

Hi David: Thanks for your review. On 2017年12月18日 16:30, David Hildenbrand wrote: > On 18.12.2017 00:40, Lan Tianyu wrote: >> Syzroot reports crash in kvm_irqfd_assign() is caused by use-after-free. >> Because kvm_irqfd_assign() and kvm_irqfd_deassign() can't run in paral

Re: [PATCH] KVM/Eventfd: Avoid crash when assign and deassign same eventfd in parallel.

Hi David: Thanks for your review. On 2017年12月18日 16:30, David Hildenbrand wrote: > On 18.12.2017 00:40, Lan Tianyu wrote: >> Syzroot reports crash in kvm_irqfd_assign() is caused by use-after-free. >> Because kvm_irqfd_assign() and kvm_irqfd_deassign() can't run in paral

[PATCH] KVM/Eventfd: Avoid crash when assign and deassign same eventfd in parallel.

n path return fault. Reported-by: Dmitry Vyukov <dvyu...@google.com> Cc: Paolo Bonzini <pbonz...@redhat.com> Cc: Radim Krčmář <rkrc...@redhat.com> Cc: Dmitry Vyukov <dvyu...@google.com> Cc: Wanpeng Li <kernel...@gmail.com> Signed-off-by: Tianyu Lan <tianyu@intel.co

[PATCH] KVM/Eventfd: Avoid crash when assign and deassign same eventfd in parallel.

Syzroot reports crash in kvm_irqfd_assign() is caused by use-after-free. Because kvm_irqfd_assign() and kvm_irqfd_deassign() can't run in parallel for same eventfd. When assign path hasn't been finished after irqfd has been added to kvm->irqfds.items list, another thead may deassign the eventfd

Re: Re: KASAN: use-after-free Write in irq_bypass_register_consumer

The root cause is that kvm_irqfd_assign() and kvm_irqfd_deassign() can't be run in parallel. Some data structure(e.g, irqfd->consumer) will be crashed because irqfd may be freed in deassign path before they are used in assign path. The other data maybe used in deassign path before initialization.

Re: Re: KASAN: use-after-free Write in irq_bypass_register_consumer

The root cause is that kvm_irqfd_assign() and kvm_irqfd_deassign() can't be run in parallel. Some data structure(e.g, irqfd->consumer) will be crashed because irqfd may be freed in deassign path before they are used in assign path. The other data maybe used in deassign path before initialization.

Re: [PATCH V2] KVM/x86: Check input paging mode when cs.l is set

On 12/14/2017 7:41 PM, Paolo Bonzini wrote: On 14/12/2017 04:55, Lan Tianyu wrote: +* When EFER.LME and CR0.PG are set, CR4.PAE and EFER.LMA +* must be set. +*/ + if ((sregs->efer & EFER_LME) && (sregs->cr0 & X86_CR0_PG_BIT)) { +

Re: [PATCH V2] KVM/x86: Check input paging mode when cs.l is set

On 12/14/2017 7:41 PM, Paolo Bonzini wrote: On 14/12/2017 04:55, Lan Tianyu wrote: +* When EFER.LME and CR0.PG are set, CR4.PAE and EFER.LMA +* must be set. +*/ + if ((sregs->efer & EFER_LME) && (sregs->cr0 & X86_CR0_PG_BIT)) { +

[PATCH V3] KVM/x86: Check input paging mode when cs.l is set

ported-by: Dmitry Vyukov <dvyu...@google.com> Cc: Paolo Bonzini <pbonz...@redhat.com> Cc: Radim Krčmář <rkrc...@redhat.com> Cc: Dmitry Vyukov <dvyu...@google.com> Cc: Jim Mattson <jmatt...@google.com> Signed-off-by: Tianyu Lan <tianyu@intel.com> --- Change since v2:

[PATCH V3] KVM/x86: Check input paging mode when cs.l is set

Reported by syzkaller: WARNING: CPU: 0 PID: 27962 at arch/x86/kvm/emulate.c:5631 x86_emulate_insn+0x557/0x15f0 [kvm] Modules linked in: kvm_intel kvm [last unloaded: kvm] CPU: 0 PID: 27962 Comm: syz-executor Tainted: GB W 4.15.0-rc2-next-20171208+ #32 Hardware name:

[PATCH V2] KVM/x86: Check input paging mode when cs.l is set

ported-by: Dmitry Vyukov <dvyu...@google.com> Cc: Paolo Bonzini <pbonz...@redhat.com> Cc: Radim Krčmář <rkrc...@redhat.com> Cc: Dmitry Vyukov <dvyu...@google.com> Cc: Jim Mattson <jmatt...@google.com> Signed-off-by: Tianyu Lan <tianyu@intel.com> --- Change since v

[PATCH V2] KVM/x86: Check input paging mode when cs.l is set

Reported by syzkaller: WARNING: CPU: 0 PID: 27962 at arch/x86/kvm/emulate.c:5631 x86_emulate_insn+0x557/0x15f0 [kvm] Modules linked in: kvm_intel kvm [last unloaded: kvm] CPU: 0 PID: 27962 Comm: syz-executor Tainted: GB W 4.15.0-rc2-next-20171208+ #32 Hardware name:

Re: [PATCH 1/1] KVM/x86: Check input paging mode when cs.l is set

On 2017年12月13日 20:20, Paolo Bonzini wrote: > On 13/12/2017 05:17, Lan Tianyu wrote: >> Reported by syzkaller: >> WARNING: CPU: 0 PID: 27962 at arch/x86/kvm/emulate.c:5631 >> x86_emulate_insn+0x557/0x15f0 [kvm] >> Modules linked in: kvm_intel kvm [last unloa

Re: [PATCH 1/1] KVM/x86: Check input paging mode when cs.l is set

On 2017年12月13日 20:20, Paolo Bonzini wrote: > On 13/12/2017 05:17, Lan Tianyu wrote: >> Reported by syzkaller: >> WARNING: CPU: 0 PID: 27962 at arch/x86/kvm/emulate.c:5631 >> x86_emulate_insn+0x557/0x15f0 [kvm] >> Modules linked in: kvm_intel kvm [last unloa

[PATCH 1/1] KVM/x86: Check input paging mode when cs.l is set

krc...@redhat.com> Cc: Dmitry Vyukov <dvyu...@google.com> Cc: Jim Mattson <jmatt...@google.com> Signed-off-by: Tianyu Lan <tianyu....@intel.com> Signed-off-by: Lan Tianyu <tianyu@intel.com> --- arch/x86/kvm/x86.c | 15 +++ 1 file changed, 15 insertions(+)

[PATCH 1/1] KVM/x86: Check input paging mode when cs.l is set

have such check when userspace inputs sreg values. This will lead unexpected behavior. This patch is to add such check. Suggested-by: Paolo Bonzini Reported-by: Dmitry Vyukov Cc: Paolo Bonzini Cc: Radim Krčmář Cc: Dmitry Vyukov Cc: Jim Mattson Signed-off-by: Tianyu Lan Signed-off-by: Lan

Re: Re: WARNING in x86_emulate_insn

On 2017年12月12日 06:45, Paolo Bonzini wrote: > On 08/12/2017 09:28, Tianyu Lan wrote: >> I find this is pop instruction emulation issue. According "SDM VOL2, >> chapter INSTRUCTION >> SET REFERENCE. POP—Pop a Value from the Stack" >> >> Protected Mode Exceptions >> #GP(0) If attempt is made to load

Re: Re: WARNING in x86_emulate_insn

On 2017年12月12日 06:45, Paolo Bonzini wrote: > On 08/12/2017 09:28, Tianyu Lan wrote: >> I find this is pop instruction emulation issue. According "SDM VOL2, >> chapter INSTRUCTION >> SET REFERENCE. POP—Pop a Value from the Stack" >> >> Protected Mode Exceptions >> #GP(0) If attempt is made to load

Re: Re: [PATCH] KVM/Emulate: Mask linear address with actual address width in order to avoid conflict with UNMAPPED_GVA

On 2017年12月12日 14:42, Wanpeng Li wrote: > 2017-12-12 7:23 GMT+08:00 Lan Tianyu <tianyu@intel.com>: >> >> Reported by syzkaller: >> WARNING: CPU: 0 PID: 27962 at arch/x86/kvm/emulate.c:5631 >> x86_emulate_insn+0x557/0x15f0 [kvm] >> Modules linke

Re: Re: [PATCH] KVM/Emulate: Mask linear address with actual address width in order to avoid conflict with UNMAPPED_GVA

On 2017年12月12日 14:42, Wanpeng Li wrote: > 2017-12-12 7:23 GMT+08:00 Lan Tianyu : >> >> Reported by syzkaller: >> WARNING: CPU: 0 PID: 27962 at arch/x86/kvm/emulate.c:5631 >> x86_emulate_insn+0x557/0x15f0 [kvm] >> Modules linked in: kvm_intel kvm [last

[PATCH] KVM/Emulate: Mask linear address with actual address width in order to avoid conflict with UNMAPPED_GVA

t;dvyu...@google.com> Cc: Paolo Bonzini <pbonz...@redhat.com> Cc: Radim Krčmář <rkrc...@redhat.com> Cc: Dmitry Vyukov <dvyu...@google.com> Cc: Jim Mattson <jmatt...@google.com> Cc: Wanpeng Li <kernel...@gmail.com> Signed-off-by: Lan Tianyu <tianyu@intel.com> ---

[PATCH] KVM/Emulate: Mask linear address with actual address width in order to avoid conflict with UNMAPPED_GVA

olo Bonzini Cc: Radim Krčmář Cc: Dmitry Vyukov Cc: Jim Mattson Cc: Wanpeng Li Signed-off-by: Lan Tianyu --- arch/x86/kvm/emulate.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c index abe74f7..9b21412 100644 --- a/arch/x86/

Re: Re: WARNING in x86_emulate_insn

On 12/8/2017 5:27 PM, Wanpeng Li wrote: 2017-12-08 16:28 GMT+08:00 Tianyu Lan : Hi Jim: Thanks for your help. 2017-12-08 5:25 GMT+08:00 Jim Mattson : Try disabling the module parameter, "unrestricted_guest." Make sure that the module

Re: Re: WARNING in x86_emulate_insn

On 12/8/2017 5:27 PM, Wanpeng Li wrote: 2017-12-08 16:28 GMT+08:00 Tianyu Lan : Hi Jim: Thanks for your help. 2017-12-08 5:25 GMT+08:00 Jim Mattson : Try disabling the module parameter, "unrestricted_guest." Make sure that the module parameter, "emulate_invalid_guest_state" is

Re: [PATCH] KVM/VMX: Avoid CR3 VMEXIT during guest real mode when "unrestricted guest" is supported.

On 2017年08月16日 17:25, Paolo Bonzini wrote: > On 16/08/2017 03:58, Lan Tianyu wrote: >> These CR3 VMEXITs was introduced for platform without "unrestricted guest" >> support. This is to set ept identity table to guest CR3 in guest real >> mode because these platforms

Re: [PATCH] KVM/VMX: Avoid CR3 VMEXIT during guest real mode when "unrestricted guest" is supported.

On 2017年08月16日 17:25, Paolo Bonzini wrote: > On 16/08/2017 03:58, Lan Tianyu wrote: >> These CR3 VMEXITs was introduced for platform without "unrestricted guest" >> support. This is to set ept identity table to guest CR3 in guest real >> mode because these platforms

Re: [PATCH] KVM/VMX: Avoid CR3 VMEXIT during guest real mode when "unrestricted guest" is supported.

On 2017年08月16日 21:26, Radim Krčmář wrote: > 2017-08-15 21:58-0400, Lan Tianyu: >> These CR3 VMEXITs was introduced for platform without "unrestricted guest" >> support. This is to set ept identity table to guest CR3 in guest real >> mode because these platforms don

Re: [PATCH] KVM/VMX: Avoid CR3 VMEXIT during guest real mode when "unrestricted guest" is supported.

On 2017年08月16日 21:26, Radim Krčmář wrote: > 2017-08-15 21:58-0400, Lan Tianyu: >> These CR3 VMEXITs was introduced for platform without "unrestricted guest" >> support. This is to set ept identity table to guest CR3 in guest real >> mode because these platforms don

[PATCH] KVM/VMX: Avoid CR3 VMEXIT during guest real mode when "unrestricted guest" is supported.

platforms with "unrestricted guest" support. Signed-off-by: Lan Tianyu <tianyu@intel.com> --- arch/x86/kvm/vmx.c | 22 +- 1 file changed, 13 insertions(+), 9 deletions(-) diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c index 9b21b12..46dcf50 100644 --- a/arch/x86/kv

[PATCH] KVM/VMX: Avoid CR3 VMEXIT during guest real mode when "unrestricted guest" is supported.

platforms with "unrestricted guest" support. Signed-off-by: Lan Tianyu --- arch/x86/kvm/vmx.c | 22 +- 1 file changed, 13 insertions(+), 9 deletions(-) diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c index 9b21b12..46dcf50 100644 --- a/arch/x86/kvm/vmx.c +++ b/arch/x86/k

[PATCH V2] KVM/x86: Increase max vcpu number to 8192

For HPC usage case, it will create a huge VM with vcpus number as same as host cpus and this requires more vcpus support in a single VM. This patch is to increase max vcpu number from 288 to 8192 which is current default maximum cpu number for Linux kernel. Signed-off-by: Lan Tianyu <tia

[PATCH V2] KVM/x86: Increase max vcpu number to 8192

For HPC usage case, it will create a huge VM with vcpus number as same as host cpus and this requires more vcpus support in a single VM. This patch is to increase max vcpu number from 288 to 8192 which is current default maximum cpu number for Linux kernel. Signed-off-by: Lan Tianyu --- arch

Re: [PATCH] KVM/x86: Increase max vcpu number to 352

On 2017年08月15日 22:10, Konrad Rzeszutek Wilk wrote: > On Tue, Aug 15, 2017 at 11:00:04AM +0800, Lan Tianyu wrote: >> On 2017年08月12日 03:35, Konrad Rzeszutek Wilk wrote: >>> On Fri, Aug 11, 2017 at 03:00:20PM +0200, Radim Krčmář wrote: >>>> 2017-08-11

Re: [PATCH] KVM/x86: Increase max vcpu number to 352

On 2017年08月15日 22:10, Konrad Rzeszutek Wilk wrote: > On Tue, Aug 15, 2017 at 11:00:04AM +0800, Lan Tianyu wrote: >> On 2017年08月12日 03:35, Konrad Rzeszutek Wilk wrote: >>> On Fri, Aug 11, 2017 at 03:00:20PM +0200, Radim Krčmář wrote: >>>> 2017-08-11

Re: [PATCH] KVM/x86: Increase max vcpu number to 352

On 2017年08月12日 03:35, Konrad Rzeszutek Wilk wrote: > On Fri, Aug 11, 2017 at 03:00:20PM +0200, Radim Krčmář wrote: >> 2017-08-11 10:11+0200, David Hildenbrand: >>> On 11.08.2017 09:49, Lan Tianyu wrote: >>>> Hi Konrad: >>>>Thanks for your revi

Re: [PATCH] KVM/x86: Increase max vcpu number to 352

On 2017年08月12日 03:35, Konrad Rzeszutek Wilk wrote: > On Fri, Aug 11, 2017 at 03:00:20PM +0200, Radim Krčmář wrote: >> 2017-08-11 10:11+0200, David Hildenbrand: >>> On 11.08.2017 09:49, Lan Tianyu wrote: >>>> Hi Konrad: >>>>Thanks for your revi

Re: [PATCH] KVM/x86: Increase max vcpu number to 352

Hi Konrad: Thanks for your review. On 2017年08月11日 01:50, Konrad Rzeszutek Wilk wrote: > On Thu, Aug 10, 2017 at 06:00:59PM +0800, Lan Tianyu wrote: >> Intel Xeon phi chip will support 352 logical threads. For HPC usage >> case, it will create a huge VM with vcpu number

Re: [PATCH] KVM/x86: Increase max vcpu number to 352

Hi Konrad: Thanks for your review. On 2017年08月11日 01:50, Konrad Rzeszutek Wilk wrote: > On Thu, Aug 10, 2017 at 06:00:59PM +0800, Lan Tianyu wrote: >> Intel Xeon phi chip will support 352 logical threads. For HPC usage >> case, it will create a huge VM with vcpu number

[PATCH] KVM/x86: Increase max vcpu number to 352

Intel Xeon phi chip will support 352 logical threads. For HPC usage case, it will create a huge VM with vcpu number as same as host cpus. This patch is to increase max vcpu number to 352. Signed-off-by: Lan Tianyu <tianyu@intel.com> --- arch/x86/include/asm/kvm_host.h | 2 +- 1 file c

[PATCH] KVM/x86: Increase max vcpu number to 352

Intel Xeon phi chip will support 352 logical threads. For HPC usage case, it will create a huge VM with vcpu number as same as host cpus. This patch is to increase max vcpu number to 352. Signed-off-by: Lan Tianyu --- arch/x86/include/asm/kvm_host.h | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH 5/7] KVM: Replace smp_mb() with smp_load_acquire() in the kvm_flush_remote_tlbs()

smp_load_acquire() is enough here and it's cheaper than smp_mb(). Adding a comment about reusing memory barrier of kvm_make_all_cpus_request() here to keep order between modifications to the page tables and reading mode. Signed-off-by: Lan Tianyu <tianyu@intel.com> --- virt/kvm/kvm_

[PATCH 6/7] KVM/x86: update the comment of memory barrier in the vcpu_enter_guest()

The barrier also orders the write to mode from any reads to the page tables done and so update the comment. Signed-off-by: Lan Tianyu <tianyu@intel.com> --- arch/x86/kvm/x86.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm

[PATCH 4/7] KVM/x86: Call smp_wmb() before increasing tlbs_dirty

Update spte before increasing tlbs_dirty to make sure no tlb flush in lost after spte is zapped. This pairs with the barrier in the kvm_flush_remote_tlbs(). Signed-off-by: Lan Tianyu <tianyu@intel.com> --- arch/x86/kvm/paging_tmpl.h | 11 +++ 1 file changed, 11 insertions(+)

[PATCH 7/7] KVM/PPC: update the comment of memory barrier in the kvmppc_prepare_to_enter()

The barrier also orders the write to mode from any reads to the page tables done and so update the comment. Signed-off-by: Lan Tianyu <tianyu@intel.com> --- arch/powerpc/kvm/powerpc.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/powerpc/kvm/powerpc.c b/arch/power

[PATCH 5/7] KVM: Replace smp_mb() with smp_load_acquire() in the kvm_flush_remote_tlbs()

smp_load_acquire() is enough here and it's cheaper than smp_mb(). Adding a comment about reusing memory barrier of kvm_make_all_cpus_request() here to keep order between modifications to the page tables and reading mode. Signed-off-by: Lan Tianyu --- virt/kvm/kvm_main.c | 18

[PATCH 6/7] KVM/x86: update the comment of memory barrier in the vcpu_enter_guest()

The barrier also orders the write to mode from any reads to the page tables done and so update the comment. Signed-off-by: Lan Tianyu --- arch/x86/kvm/x86.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index bcbce0f..4bdb4e6

[PATCH 4/7] KVM/x86: Call smp_wmb() before increasing tlbs_dirty

Update spte before increasing tlbs_dirty to make sure no tlb flush in lost after spte is zapped. This pairs with the barrier in the kvm_flush_remote_tlbs(). Signed-off-by: Lan Tianyu --- arch/x86/kvm/paging_tmpl.h | 11 +++ 1 file changed, 11 insertions(+) diff --git a/arch/x86/kvm

[PATCH 7/7] KVM/PPC: update the comment of memory barrier in the kvmppc_prepare_to_enter()

The barrier also orders the write to mode from any reads to the page tables done and so update the comment. Signed-off-by: Lan Tianyu --- arch/powerpc/kvm/powerpc.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c index 19aa59b

[PATCH 1/7] KVM: Remove redundant smp_mb() in the kvm_mmu_commit_zap_page()

There is already a barrier inside of kvm_flush_remote_tlbs() which can help to make sure everyone sees our modifications to the page tables and see changes to vcpu->mode here. So remove the smp_mb in the kvm_mmu_commit_zap_page() and update the comment. Signed-off-by: Lan Tianyu <

[PATCH 1/7] KVM: Remove redundant smp_mb() in the kvm_mmu_commit_zap_page()

There is already a barrier inside of kvm_flush_remote_tlbs() which can help to make sure everyone sees our modifications to the page tables and see changes to vcpu->mode here. So remove the smp_mb in the kvm_mmu_commit_zap_page() and update the comment. Signed-off-by: Lan Tianyu --- arch/

[PATCH 0/7] KVM/X86/PPC: Clear up kvm mmu memory barriers and update related comments

This series is to clear up kvm mmu memory barriers. 1) Remove redundant barrier (PATCH 1) 2) Replace origin barrier functions with preferrable ones (PATCH 2, 3, 5) 3) Fix unpaired barriers (PATCH 4) 4) Update or add barrier related comments (PATCH 6, 7) Lan Tianyu (7): KVM: Remove redundant

[PATCH 2/7] KVM/x86: Replace smp_mb() with smp_store_mb/release() in the walk_shadow_page_lockless_begin/end()

Signed-off-by: Lan Tianyu <tianyu@intel.com> --- arch/x86/kvm/mmu.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c index 5e795af..d1ee68c 100644 --- a/arch/x86/kvm/mmu.c +++ b/arch/x86/kvm/mmu.c @@ -632,12 +632,12 @@

[PATCH 3/7] KVM: Replace smp_mb() with smp_mb_after_atomic() in the kvm_make_all_cpus_request()

Signed-off-by: Lan Tianyu <tianyu@intel.com> --- virt/kvm/kvm_main.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index 1eae052..ec5aa8d 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -170,8 +170,8 @

[PATCH 2/7] KVM/x86: Replace smp_mb() with smp_store_mb/release() in the walk_shadow_page_lockless_begin/end()

Signed-off-by: Lan Tianyu --- arch/x86/kvm/mmu.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c index 5e795af..d1ee68c 100644 --- a/arch/x86/kvm/mmu.c +++ b/arch/x86/kvm/mmu.c @@ -632,12 +632,12 @@ static void

[PATCH 3/7] KVM: Replace smp_mb() with smp_mb_after_atomic() in the kvm_make_all_cpus_request()

Signed-off-by: Lan Tianyu --- virt/kvm/kvm_main.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index 1eae052..ec5aa8d 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -170,8 +170,8 @@ bool kvm_make_all_cpus_request

[PATCH 0/7] KVM/X86/PPC: Clear up kvm mmu memory barriers and update related comments

This series is to clear up kvm mmu memory barriers. 1) Remove redundant barrier (PATCH 1) 2) Replace origin barrier functions with preferrable ones (PATCH 2, 3, 5) 3) Fix unpaired barriers (PATCH 4) 4) Update or add barrier related comments (PATCH 6, 7) Lan Tianyu (7): KVM: Remove redundant

Re: [PATCH] KVM: Remove redundant smp_mb() in the kvm_mmu_commit_zap_page()

On 2016年03月10日 23:26, Paolo Bonzini wrote: > > > On 10/03/2016 15:40, Xiao Guangrong wrote: >> long dirty_count = kvm->tlbs_dirty; >> >> +/* >> + * read tlbs_dirty before doing tlb flush to make sure not tlb >> request is >> + * lost. >> + */ >>

Re: [PATCH] KVM: Remove redundant smp_mb() in the kvm_mmu_commit_zap_page()

On 2016年03月10日 23:26, Paolo Bonzini wrote: > > > On 10/03/2016 15:40, Xiao Guangrong wrote: >> long dirty_count = kvm->tlbs_dirty; >> >> +/* >> + * read tlbs_dirty before doing tlb flush to make sure not tlb >> request is >> + * lost. >> + */ >>

Re: [PATCH] KVM: Remove redundant smp_mb() in the kvm_mmu_commit_zap_page()

On 2016年03月08日 23:27, Paolo Bonzini wrote: > Unfortunately that patch added a bad memory barrier: 1) it lacks a > comment; 2) it lacks obvious pairing; 3) it is an smp_mb() after a read, > so it's not even obvious that this memory barrier has to do with the > immediately preceding read of

Re: [PATCH] KVM: Remove redundant smp_mb() in the kvm_mmu_commit_zap_page()

On 2016年03月08日 23:27, Paolo Bonzini wrote: > Unfortunately that patch added a bad memory barrier: 1) it lacks a > comment; 2) it lacks obvious pairing; 3) it is an smp_mb() after a read, > so it's not even obvious that this memory barrier has to do with the > immediately preceding read of

Re: [PATCH] KVM: Remove redundant smp_mb() in the kvm_mmu_commit_zap_page()

On 2016年03月04日 16:49, Paolo Bonzini wrote: > On 04/03/2016 08:12, Lan Tianyu wrote: >>>>/* >>>> - * wmb: make sure everyone sees our modifications to the page tables >>>> - * rmb: make sure we see changes to vcpu->mode >>> >>>

Re: [PATCH] KVM: Remove redundant smp_mb() in the kvm_mmu_commit_zap_page()

On 2016年03月04日 16:49, Paolo Bonzini wrote: > On 04/03/2016 08:12, Lan Tianyu wrote: >>>>/* >>>> - * wmb: make sure everyone sees our modifications to the page tables >>>> - * rmb: make sure we see changes to vcpu->mode >>> >>>

Re: [PATCH] KVM: Remove redundant smp_mb() in the kvm_mmu_commit_zap_page()

On 2016年03月04日 15:21, Thomas Gleixner wrote: > On Fri, 4 Mar 2016, Lan Tianyu wrote: > >> The following kvm_flush_remote_tlbs() will call smp_mb() inside and so >> remove smp_mb() here. >> >> Signed-off-by: Lan Tianyu <tianyu@intel.com> >> --- &g

Re: [PATCH] KVM: Remove redundant smp_mb() in the kvm_mmu_commit_zap_page()

On 2016年03月04日 15:21, Thomas Gleixner wrote: > On Fri, 4 Mar 2016, Lan Tianyu wrote: > >> The following kvm_flush_remote_tlbs() will call smp_mb() inside and so >> remove smp_mb() here. >> >> Signed-off-by: Lan Tianyu >> --- >> arch/x86/kvm/mmu.c

[PATCH] KVM: Remove redundant smp_mb() in the kvm_mmu_commit_zap_page()

The following kvm_flush_remote_tlbs() will call smp_mb() inside and so remove smp_mb() here. Signed-off-by: Lan Tianyu <tianyu@intel.com> --- arch/x86/kvm/mmu.c | 6 -- 1 file changed, 6 deletions(-) diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c index a54ecd9..6315416

[PATCH] KVM: Remove redundant smp_mb() in the kvm_mmu_commit_zap_page()

The following kvm_flush_remote_tlbs() will call smp_mb() inside and so remove smp_mb() here. Signed-off-by: Lan Tianyu --- arch/x86/kvm/mmu.c | 6 -- 1 file changed, 6 deletions(-) diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c index a54ecd9..6315416 100644 --- a/arch/x86/kvm/mmu.c

Re: [PATCH] KVM: Replace the number of page entries per page with PT64_ENT_PER_PAGE macro

Sorry. Miss some other modifications and please ignore this version. On 3/1/2016 10:49 PM, Lan Tianyu wrote: This patch is to make code more readable. Signed-off-by: Lan Tianyu <tianyu@intel.com> --- arch/x86/include/asm/kvm_host.h | 2 +- arch/x86/kvm/mmu.c | 2

Re: [PATCH] KVM: Replace the number of page entries per page with PT64_ENT_PER_PAGE macro

Sorry. Miss some other modifications and please ignore this version. On 3/1/2016 10:49 PM, Lan Tianyu wrote: This patch is to make code more readable. Signed-off-by: Lan Tianyu --- arch/x86/include/asm/kvm_host.h | 2 +- arch/x86/kvm/mmu.c | 2 +- 2 files changed, 2

[PATCH] KVM: Replace the number of page entries per page with PT64_ENT_PER_PAGE macro

This patch is to make code more readable. Signed-off-by: Lan Tianyu <tianyu@intel.com> --- arch/x86/include/asm/kvm_host.h | 2 +- arch/x86/kvm/mmu.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/inclu

[PATCH] KVM: Replace the number of page entries per page with PT64_ENT_PER_PAGE macro

This patch is to make code more readable. Signed-off-by: Lan Tianyu --- arch/x86/include/asm/kvm_host.h | 2 +- arch/x86/kvm/mmu.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h index 44adbb8

Re: [RFC PATCH V2 0/3] IXGBE/VFIO: Add live migration support for SRIOV NIC

On 12/9/2015 7:28 PM, Michael S. Tsirkin wrote: I remember reading that it's possible to implement a bus driver on windows if required. But basically I don't see how windows can be relevant to discussing guest driver patches. That discussion probably belongs on the qemu maling list, not on

Re: [RFC PATCH V2 0/3] IXGBE/VFIO: Add live migration support for SRIOV NIC

On 12/9/2015 6:37 PM, Michael S. Tsirkin wrote: On Sat, Dec 05, 2015 at 12:32:00AM +0800, Lan, Tianyu wrote: Hi Michael & Alexander: Thanks a lot for your comments and suggestions. It's nice that it's appreciated, but you then go on and ignore all that I have written here: https://www.

Re: [RFC PATCH V2 0/3] IXGBE/VFIO: Add live migration support for SRIOV NIC

On 12/8/2015 1:12 AM, Alexander Duyck wrote: On Mon, Dec 7, 2015 at 7:40 AM, Lan, Tianyu wrote: On 12/5/2015 1:07 AM, Alexander Duyck wrote: We still need to support Windows guest for migration and this is why our patches keep all changes in the driver since it's impossible to change

Re: [RFC PATCH V2 0/3] IXGBE/VFIO: Add live migration support for SRIOV NIC

On 12/8/2015 1:12 AM, Alexander Duyck wrote: On Mon, Dec 7, 2015 at 7:40 AM, Lan, Tianyu <tianyu@intel.com> wrote: On 12/5/2015 1:07 AM, Alexander Duyck wrote: We still need to support Windows guest for migration and this is why our patches keep all changes in the driver sinc

Re: [RFC PATCH V2 0/3] IXGBE/VFIO: Add live migration support for SRIOV NIC

On 12/9/2015 6:37 PM, Michael S. Tsirkin wrote: On Sat, Dec 05, 2015 at 12:32:00AM +0800, Lan, Tianyu wrote: Hi Michael & Alexander: Thanks a lot for your comments and suggestions. It's nice that it's appreciated, but you then go on and ignore all that I have written here: https://www.

Re: [RFC PATCH V2 0/3] IXGBE/VFIO: Add live migration support for SRIOV NIC

On 12/9/2015 7:28 PM, Michael S. Tsirkin wrote: I remember reading that it's possible to implement a bus driver on windows if required. But basically I don't see how windows can be relevant to discussing guest driver patches. That discussion probably belongs on the qemu maling list, not on

Re: [RFC PATCH V2 0/3] IXGBE/VFIO: Add live migration support for SRIOV NIC

On 12/5/2015 1:07 AM, Alexander Duyck wrote: We still need to support Windows guest for migration and this is why our patches keep all changes in the driver since it's impossible to change Windows kernel. That is a poor argument. I highly doubt Microsoft is interested in having to modify all

Re: [RFC PATCH V2 0/3] IXGBE/VFIO: Add live migration support for SRIOV NIC

On 12/5/2015 1:07 AM, Alexander Duyck wrote: We still need to support Windows guest for migration and this is why our patches keep all changes in the driver since it's impossible to change Windows kernel. That is a poor argument. I highly doubt Microsoft is interested in having to modify all

Re: [RFC PATCH V2 0/3] IXGBE/VFIO: Add live migration support for SRIOV NIC

Hi Michael & Alexander: Thanks a lot for your comments and suggestions. We still need to support Windows guest for migration and this is why our patches keep all changes in the driver since it's impossible to change Windows kernel. Following is my idea to do DMA tracking. Inject event to VF

Re: [RFC PATCH V2 0/3] IXGBE/VFIO: Add live migration support for SRIOV NIC

Hi Michael & Alexander: Thanks a lot for your comments and suggestions. We still need to support Windows guest for migration and this is why our patches keep all changes in the driver since it's impossible to change Windows kernel. Following is my idea to do DMA tracking. Inject event to VF

Re: [RFC PATCH V2 0/3] IXGBE/VFIO: Add live migration support for SRIOV NIC

On 12/1/2015 12:07 AM, Alexander Duyck wrote: They can only be corrected if the underlying assumptions are correct and they aren't. Your solution would have never worked correctly. The problem is you assume you can keep the device running when you are migrating and you simply cannot. At some

Re: [RFC PATCH V2 0/3] IXGBE/VFIO: Add live migration support for SRIOV NIC

On 12/1/2015 12:07 AM, Alexander Duyck wrote: They can only be corrected if the underlying assumptions are correct and they aren't. Your solution would have never worked correctly. The problem is you assume you can keep the device running when you are migrating and you simply cannot. At some

Re: [RFC PATCH V2 0/3] IXGBE/VFIO: Add live migration support for SRIOV NIC

On 11/26/2015 11:56 AM, Alexander Duyck wrote: > I am not saying you cannot modify the drivers, however what you are doing is far too invasive. Do you seriously plan on modifying all of the PCI device drivers out there in order to allow any device that might be direct assigned to a port to

Re: [RFC PATCH V2 0/3] IXGBE/VFIO: Add live migration support for SRIOV NIC

On 11/26/2015 11:56 AM, Alexander Duyck wrote: > I am not saying you cannot modify the drivers, however what you are doing is far too invasive. Do you seriously plan on modifying all of the PCI device drivers out there in order to allow any device that might be direct assigned to a port to

Re: [RFC PATCH V2 3/3] Ixgbevf: Add migration support for ixgbevf driver

On 11/25/2015 8:28 PM, Michael S. Tsirkin wrote: Frankly, I don't really see what this short term hack buys us, and if it goes in, we'll have to maintain it forever. The framework of how to notify VF about migration status won't be changed regardless of stopping VF or not before doing

Re: [RFC PATCH V2 0/3] IXGBE/VFIO: Add live migration support for SRIOV NIC

On 2015年11月25日 13:30, Alexander Duyck wrote: > No, what I am getting at is that you can't go around and modify the > configuration space for every possible device out there. This > solution won't scale. PCI config space regs are emulation by Qemu and so We can find the free PCI config space

Re: [RFC PATCH V2 3/3] Ixgbevf: Add migration support for ixgbevf driver

On 11/25/2015 8:28 PM, Michael S. Tsirkin wrote: Frankly, I don't really see what this short term hack buys us, and if it goes in, we'll have to maintain it forever. The framework of how to notify VF about migration status won't be changed regardless of stopping VF or not before doing

Re: [RFC PATCH V2 0/3] IXGBE/VFIO: Add live migration support for SRIOV NIC

On 2015年11月25日 13:30, Alexander Duyck wrote: > No, what I am getting at is that you can't go around and modify the > configuration space for every possible device out there. This > solution won't scale. PCI config space regs are emulation by Qemu and so We can find the free PCI config space

Re: [RFC PATCH V2 3/3] Ixgbevf: Add migration support for ixgbevf driver

On 2015年11月25日 05:20, Michael S. Tsirkin wrote: > I have to say, I was much more interested in the idea > of tracking dirty memory. I have some thoughts about > that one - did you give up on it then? No, our finial target is to keep VF active before doing migration and tracking dirty memory is

  1   2   3   4   5   6   7   8   >