Re: [PATCH] kvm: lapic: fix broken vcpu hotplug

On Mon, 22 Jun 2020 18:47:57 +0200 Paolo Bonzini wrote: > On 22/06/20 18:08, Igor Mammedov wrote: > > Guest fails to online hotplugged CPU with error > > smpboot: do_boot_cpu failed(-1) to wakeup CPU#4 > > > > It's caused by the fact that kvm_apic_set_

[PATCH] kvm: lapic: fix broken vcpu hotplug

. Fix issue by forcing unconditional update from kvm_apic_set_state(), like it used to be. 1) Fixes: (4abaffce4d25a KVM: LAPIC: Recalculate apic map in batch) Signed-off-by: Igor Mammedov --- PS: it's alternative to full revert of [1], I've posted earlier https://www.mail-archive.com/linux-kernel

[PATCH] Revert "KVM: LAPIC: Recalculate apic map in batch"

4abaffce4d25aa41392d2e81835592726d757857. Signed-off-by: Igor Mammedov --- arch/x86/include/asm/kvm_host.h | 1 - arch/x86/kvm/lapic.h| 1 - arch/x86/kvm/lapic.c| 46 +++-- arch/x86/kvm/x86.c | 1 - 4 files changed, 10 insertions(+), 39 deletions(-) diff

Re: [PATCH v3] KVM: LAPIC: Recalculate apic map in batch

On Fri, 19 Jun 2020 16:10:43 +0200 Paolo Bonzini wrote: > On 19/06/20 14:36, Igor Mammedov wrote: > > qemu-kvm -m 2G -smp 4,maxcpus=8 -monitor stdio > > (qemu) device_add qemu64-x86_64-cpu,socket-id=4,core-id=0,thread-id=0 > > > > in guest fails with: > > &g

Re: [PATCH v3] KVM: LAPIC: Recalculate apic map in batch

On Fri, 19 Jun 2020 16:10:43 +0200 Paolo Bonzini wrote: > On 19/06/20 14:36, Igor Mammedov wrote: > > qemu-kvm -m 2G -smp 4,maxcpus=8 -monitor stdio > > (qemu) device_add qemu64-x86_64-cpu,socket-id=4,core-id=0,thread-id=0 > > > > in guest fails with: > > &g

Re: [PATCH v3] KVM: LAPIC: Recalculate apic map in batch

On Wed, 26 Feb 2020 10:41:02 +0800 Wanpeng Li wrote: > From: Wanpeng Li > > In the vCPU reset and set APIC_BASE MSR path, the apic map will be > recalculated > several times, each time it will consume 10+ us observed by ftrace in my > non-overcommit environment since the expensive memory

[PATCH v2] KVM: s390: kvm_s390_vm_start_migration: check dirty_bitmap before using it as target for memset()

turned off. Last Breaking-Event-Address: [<00dbaf60>] __memset+0xc/0xa0 due to ms->dirty_bitmap being NULL, which might crash the host. Make sure that ms->dirty_bitmap is set before using it or return -ENIVAL otherwise. Fixes: afdad61615cc ("KVM: s390: Fix storage at

[PATCH] KVM: s390: kvm_s390_vm_start_migration: check dirty_bitmap before using it as target for memset()

: s390: Fix storage attributes migration with memory slots") Signed-off-by: Igor Mammedov --- Cc: sta...@vger.kernel.org # v4.19+ v2: - drop WARN() arch/s390/kvm/kvm-s390.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c index

Re: [PATCH] kvm_s390_vm_start_migration: check dirty_bitmap before using it as target for memset()

On Mon, 9 Sep 2019 17:47:37 +0200 David Hildenbrand wrote: > On 09.09.19 16:55, Igor Mammedov wrote: > > If userspace doesn't set KVM_MEM_LOG_DIRTY_PAGES on memslot before calling > > kvm_s390_vm_start_migration(), kernel will oops with: > > > > We usually have

[PATCH] kvm_s390_vm_start_migration: check dirty_bitmap before using it as target for memset()

turned off. Last Breaking-Event-Address: [<00dbaf60>] __memset+0xc/0xa0 due to ms->dirty_bitmap being NULL, which migh crash the host. Make sure that ms->dirty_bitmap is set before using it or print a warning and return -ENIVAL otherwise. Signed-off-by: Igor Mammedov --

Re: cpu/hotplug: broken sibling thread hotplug

On Mon, 28 Jan 2019 06:52:52 -0600 Josh Poimboeuf wrote: > On Mon, Jan 28, 2019 at 11:13:04AM +0100, Igor Mammedov wrote: > > On Fri, 25 Jan 2019 11:02:03 -0600 > > Josh Poimboeuf wrote: > > > > > On Fri, Jan 25, 2019 at 10:36:57AM -0600, Josh Poimboeuf wrote:

Re: cpu/hotplug: broken sibling thread hotplug

On Fri, 25 Jan 2019 11:02:03 -0600 Josh Poimboeuf wrote: > On Fri, Jan 25, 2019 at 10:36:57AM -0600, Josh Poimboeuf wrote: > > How about this patch? It's just a revert of 73d5e2b47264 and > > bc2d8d262cba, plus the 1-line vmx_vm_init() change. If it looks ok to > > you, I can clean it up and

cpu/hotplug: broken sibling thread hotplug

In case guest is booted with one CPU present and then later a sibling CPU is hotplugged [1], it stays offline since SMT is disabled. Bisects to 73d5e2b47264 ("cpu/hotplug: detect SMT disabled by BIOS") which used __max_smt_threads to decide disabling SMT and in case [1] only primary CPU thread

Re: [Qemu-devel] [PATCH v11 2/6] ACPI: Add APEI GHES Table Generation support

On Fri, 1 Sep 2017 17:58:55 +0800 gengdongjiu <gengdong...@huawei.com> wrote: > Hi Igor, > > On 2017/8/29 18:20, Igor Mammedov wrote: > > On Fri, 18 Aug 2017 22:23:43 +0800 > > Dongjiu Geng <gengdong...@huawei.com> wrote: [...] > > > >>

Re: [Qemu-devel] [PATCH v11 2/6] ACPI: Add APEI GHES Table Generation support

On Fri, 1 Sep 2017 17:58:55 +0800 gengdongjiu wrote: > Hi Igor, > > On 2017/8/29 18:20, Igor Mammedov wrote: > > On Fri, 18 Aug 2017 22:23:43 +0800 > > Dongjiu Geng wrote: [...] > > > >> +void ghes_build_acpi(GArray

Re: [Qemu-devel] [PATCH v11 2/6] ACPI: Add APEI GHES Table Generation support

On Fri, 18 Aug 2017 22:23:43 +0800 Dongjiu Geng wrote: > This implements APEI GHES Table by passing the error CPER info > to the guest via a fw_cfg_blob. After a CPER info is recorded, an > SEA(Synchronous External Abort)/SEI(SError Interrupt) exception > will be injected

Re: [Qemu-devel] [PATCH v11 2/6] ACPI: Add APEI GHES Table Generation support

On Fri, 18 Aug 2017 22:23:43 +0800 Dongjiu Geng wrote: > This implements APEI GHES Table by passing the error CPER info > to the guest via a fw_cfg_blob. After a CPER info is recorded, an > SEA(Synchronous External Abort)/SEI(SError Interrupt) exception > will be injected into the guest OS.

Re: [RFC PATCH 0/5] mm, memory_hotplug: allocate memmap from hotadded memory

On Mon, 31 Jul 2017 19:58:30 +0200 Gerald Schaefer wrote: > On Mon, 31 Jul 2017 17:53:50 +0200 > Michal Hocko wrote: > > > On Mon 31-07-17 17:04:59, Gerald Schaefer wrote: > > > On Mon, 31 Jul 2017 14:53:19 +0200 > > > Michal Hocko

Re: [RFC PATCH 0/5] mm, memory_hotplug: allocate memmap from hotadded memory

On Mon, 31 Jul 2017 19:58:30 +0200 Gerald Schaefer wrote: > On Mon, 31 Jul 2017 17:53:50 +0200 > Michal Hocko wrote: > > > On Mon 31-07-17 17:04:59, Gerald Schaefer wrote: > > > On Mon, 31 Jul 2017 14:53:19 +0200 > > > Michal Hocko wrote: > > > > > > > On Mon 31-07-17 14:35:21, Gerald

Re: [RFC PATCH 2/2] mm, memory_hotplug: drop CONFIG_MOVABLE_NODE

On Wed, 24 May 2017 14:24:11 +0200 Michal Hocko wrote: [...] > index facc20a3f962..ec7d6ae01c96 100644 > --- a/Documentation/admin-guide/kernel-parameters.txt > +++ b/Documentation/admin-guide/kernel-parameters.txt > @@ -2246,8 +2246,11 @@ [...] > +

Re: [RFC PATCH 2/2] mm, memory_hotplug: drop CONFIG_MOVABLE_NODE

On Wed, 24 May 2017 14:24:11 +0200 Michal Hocko wrote: [...] > index facc20a3f962..ec7d6ae01c96 100644 > --- a/Documentation/admin-guide/kernel-parameters.txt > +++ b/Documentation/admin-guide/kernel-parameters.txt > @@ -2246,8 +2246,11 @@ [...] > + movable. This means that

Re: [PATCH -v2 0/9] mm: make movable onlining suck less

On Tue, 11 Apr 2017 11:23:07 +0200 Michal Hocko <mho...@kernel.org> wrote: > On Tue 11-04-17 08:38:34, Igor Mammedov wrote: > > for issue2: > > -enable-kvm -m 2G,slots=4,maxmem=4G -smp 4 -numa node -numa node \ > > -drive if=virtio,file=disk.img -kernel bzIm

Re: [PATCH -v2 0/9] mm: make movable onlining suck less

On Tue, 11 Apr 2017 11:23:07 +0200 Michal Hocko wrote: > On Tue 11-04-17 08:38:34, Igor Mammedov wrote: > > for issue2: > > -enable-kvm -m 2G,slots=4,maxmem=4G -smp 4 -numa node -numa node \ > > -drive if=virtio,file=disk.img -kernel bzImage -append 'root=/dev/vda1' \ >

Re: [PATCH -v2 0/9] mm: make movable onlining suck less

On Tue, 11 Apr 2017 10:41:42 +0200 Michal Hocko <mho...@kernel.org> wrote: > On Tue 11-04-17 10:01:52, Igor Mammedov wrote: > > On Mon, 10 Apr 2017 16:56:39 +0200 > > Michal Hocko <mho...@kernel.org> wrote: > [...] > > > > #echo online_kernel >

Re: [PATCH -v2 0/9] mm: make movable onlining suck less

On Tue, 11 Apr 2017 10:41:42 +0200 Michal Hocko wrote: > On Tue 11-04-17 10:01:52, Igor Mammedov wrote: > > On Mon, 10 Apr 2017 16:56:39 +0200 > > Michal Hocko wrote: > [...] > > > > #echo online_kernel > memory32/state > > > > write error:

Re: [PATCH -v2 0/9] mm: make movable onlining suck less

On Mon, 10 Apr 2017 16:56:39 +0200 Michal Hocko <mho...@kernel.org> wrote: > On Mon 10-04-17 16:27:49, Igor Mammedov wrote: > [...] > > Hi Michal, > > > > I've given series some dumb testing, see below for unexpected changes I've > > noticed. >

Re: [PATCH -v2 0/9] mm: make movable onlining suck less

On Mon, 10 Apr 2017 16:56:39 +0200 Michal Hocko wrote: > On Mon 10-04-17 16:27:49, Igor Mammedov wrote: > [...] > > Hi Michal, > > > > I've given series some dumb testing, see below for unexpected changes I've > > noticed. > > > > Using the same CL

Re: [PATCH -v2 0/9] mm: make movable onlining suck less

On Mon, 10 Apr 2017 18:09:41 +0200 Michal Hocko <mho...@kernel.org> wrote: > On Mon 10-04-17 16:27:49, Igor Mammedov wrote: > [...] > > -object memory-backend-ram,id=mem1,size=256M -object > > memory-backend-ram,id=mem0,size=256M \ > > -device pc-dimm,id=dimm1,mem

Re: [PATCH -v2 0/9] mm: make movable onlining suck less

On Mon, 10 Apr 2017 18:09:41 +0200 Michal Hocko wrote: > On Mon 10-04-17 16:27:49, Igor Mammedov wrote: > [...] > > -object memory-backend-ram,id=mem1,size=256M -object > > memory-backend-ram,id=mem0,size=256M \ > > -device pc-dimm,id=dimm1,memdev=mem1,slot=1,node=0

Re: [PATCH -v2 0/9] mm: make movable onlining suck less

On Mon, 10 Apr 2017 13:03:42 +0200 Michal Hocko wrote: > Hi, > The last version of this series has been posted here [1]. It has seen > some more serious testing (thanks to Reza Arbab) and fixes for the found > issues. I have also decided to drop patch 1 [2] because it turned

Re: [PATCH -v2 0/9] mm: make movable onlining suck less

On Mon, 10 Apr 2017 13:03:42 +0200 Michal Hocko wrote: > Hi, > The last version of this series has been posted here [1]. It has seen > some more serious testing (thanks to Reza Arbab) and fixes for the found > issues. I have also decided to drop patch 1 [2] because it turned out to > be more

Re: [PATCH v1 1/6] mm: get rid of zone_is_initialized

On Wed, 5 Apr 2017 10:14:00 +0200 Michal Hocko wrote: > On Fri 31-03-17 09:39:54, Michal Hocko wrote: > > Fixed screw ups during the initial patch split up as per Hillf > > --- > > From 8be6c5e47de66210e47710c80e72e8abd899017b Mon Sep 17 00:00:00 2001 > > From: Michal Hocko

Re: [PATCH v1 1/6] mm: get rid of zone_is_initialized

On Wed, 5 Apr 2017 10:14:00 +0200 Michal Hocko wrote: > On Fri 31-03-17 09:39:54, Michal Hocko wrote: > > Fixed screw ups during the initial patch split up as per Hillf > > --- > > From 8be6c5e47de66210e47710c80e72e8abd899017b Mon Sep 17 00:00:00 2001 > > From: Michal Hocko > > Date: Wed, 29

Re: [PATCH 0/6] mm: make movable onlining suck less

On Mon, 3 Apr 2017 13:55:46 +0200 Michal Hocko wrote: > On Thu 30-03-17 13:54:48, Michal Hocko wrote: > [...] > > Any thoughts, complains, suggestions? > > Anyting? I would really appreciate a feedback from IBM and Futjitsu guys > who have shaped this code last few years.

Re: [PATCH 0/6] mm: make movable onlining suck less

On Mon, 3 Apr 2017 13:55:46 +0200 Michal Hocko wrote: > On Thu 30-03-17 13:54:48, Michal Hocko wrote: > [...] > > Any thoughts, complains, suggestions? > > Anyting? I would really appreciate a feedback from IBM and Futjitsu guys > who have shaped this code last few years. Also Igor and Vitaly

Re: ZONE_NORMAL vs. ZONE_MOVABLE

On Thu, 16 Mar 2017 20:01:25 +0100 Andrea Arcangeli wrote: [...] > If we can make zone overlap work with a 100% overlap across the whole > node that would be a fine alternative, the zoneinfo.py output will > look weird, but if that's the only downside it's no big deal. With

Re: ZONE_NORMAL vs. ZONE_MOVABLE

On Thu, 16 Mar 2017 20:01:25 +0100 Andrea Arcangeli wrote: [...] > If we can make zone overlap work with a 100% overlap across the whole > node that would be a fine alternative, the zoneinfo.py output will > look weird, but if that's the only downside it's no big deal. With > sticky movable

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

On Mon, 13 Mar 2017 13:28:25 +0100 Michal Hocko <mho...@kernel.org> wrote: > On Mon 13-03-17 11:55:54, Igor Mammedov wrote: > > On Thu, 9 Mar 2017 13:54:00 +0100 > > Michal Hocko <mho...@kernel.org> wrote: > > > > [...] > > > > It's ma

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

On Mon, 13 Mar 2017 13:28:25 +0100 Michal Hocko wrote: > On Mon 13-03-17 11:55:54, Igor Mammedov wrote: > > On Thu, 9 Mar 2017 13:54:00 +0100 > > Michal Hocko wrote: > > > > [...] > > > > It's major regression if you remove auto online in kernels th

Re: WTH is going on with memory hotplug sysf interface (was: Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks)

On Mon, 13 Mar 2017 11:43:02 +0100 Michal Hocko <mho...@kernel.org> wrote: > On Mon 13-03-17 11:31:10, Igor Mammedov wrote: > > On Fri, 10 Mar 2017 14:58:07 +0100 > [...] > > > [0.00] ACPI: SRAT: Node 0 PXM 0 [mem 0x-0x0009] > > > [0.0

Re: WTH is going on with memory hotplug sysf interface (was: Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks)

On Mon, 13 Mar 2017 11:43:02 +0100 Michal Hocko wrote: > On Mon 13-03-17 11:31:10, Igor Mammedov wrote: > > On Fri, 10 Mar 2017 14:58:07 +0100 > [...] > > > [0.00] ACPI: SRAT: Node 0 PXM 0 [mem 0x-0x0009] > > > [0.00] ACPI: SRAT

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

On Thu, 9 Mar 2017 13:54:00 +0100 Michal Hocko wrote: [...] > > It's major regression if you remove auto online in kernels that > > run on top of x86 kvm/vmware hypervisors, making API cleanups > > while breaking useful functionality doesn't make sense. > > > > I would ACK

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

On Thu, 9 Mar 2017 13:54:00 +0100 Michal Hocko wrote: [...] > > It's major regression if you remove auto online in kernels that > > run on top of x86 kvm/vmware hypervisors, making API cleanups > > while breaking useful functionality doesn't make sense. > > > > I would ACK config option removal

Re: WTH is going on with memory hotplug sysf interface (was: Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks)

re allowed from > last blocks. More below. > > On Thu 09-03-17 13:54:00, Michal Hocko wrote: > > On Tue 07-03-17 13:40:04, Igor Mammedov wrote: > > > On Mon, 6 Mar 2017 15:54:17 +0100 > > > Michal Hocko <mho...@kernel.org> wrote: > >

Re: WTH is going on with memory hotplug sysf interface (was: Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks)

blocks. More below. > > On Thu 09-03-17 13:54:00, Michal Hocko wrote: > > On Tue 07-03-17 13:40:04, Igor Mammedov wrote: > > > On Mon, 6 Mar 2017 15:54:17 +0100 > > > Michal Hocko wrote: > > > > > > > On Fri 03-03-17 18:34:22, Igor Mammedov wrote:

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

On Mon, 6 Mar 2017 15:54:17 +0100 Michal Hocko <mho...@kernel.org> wrote: > On Fri 03-03-17 18:34:22, Igor Mammedov wrote: > > On Fri, 3 Mar 2017 09:27:23 +0100 > > Michal Hocko <mho...@kernel.org> wrote: > > > > > On Thu 02-03-17 18:03:15, Igor Mamme

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

On Mon, 6 Mar 2017 15:54:17 +0100 Michal Hocko wrote: > On Fri 03-03-17 18:34:22, Igor Mammedov wrote: > > On Fri, 3 Mar 2017 09:27:23 +0100 > > Michal Hocko wrote: > > > > > On Thu 02-03-17 18:03:15, Igor Mammedov wrote: > > > > On Thu, 2 Ma

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

On Fri, 3 Mar 2017 09:27:23 +0100 Michal Hocko <mho...@kernel.org> wrote: > On Thu 02-03-17 18:03:15, Igor Mammedov wrote: > > On Thu, 2 Mar 2017 15:28:16 +0100 > > Michal Hocko <mho...@kernel.org> wrote: > > > > > On Thu 02-03-17 14:53:48, Igor

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

On Fri, 3 Mar 2017 09:27:23 +0100 Michal Hocko wrote: > On Thu 02-03-17 18:03:15, Igor Mammedov wrote: > > On Thu, 2 Mar 2017 15:28:16 +0100 > > Michal Hocko wrote: > > > > > On Thu 02-03-17 14:53:48, Igor Mammedov wrote: > > > [...] > > >

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

On Thu, 2 Mar 2017 15:28:16 +0100 Michal Hocko <mho...@kernel.org> wrote: > On Thu 02-03-17 14:53:48, Igor Mammedov wrote: > [...] > > When trying to support memory unplug on guest side in RHEL7, > > experience shows otherwise. Simplistic udev rule which onlines >

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

On Thu, 2 Mar 2017 15:28:16 +0100 Michal Hocko wrote: > On Thu 02-03-17 14:53:48, Igor Mammedov wrote: > [...] > > When trying to support memory unplug on guest side in RHEL7, > > experience shows otherwise. Simplistic udev rule which onlines > > added block doesn'

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

On Mon 27-02-17 16:43:04, Michal Hocko wrote: > On Mon 27-02-17 12:25:10, Heiko Carstens wrote: > > On Mon, Feb 27, 2017 at 11:02:09AM +0100, Vitaly Kuznetsov wrote: > > > A couple of other thoughts: > > > 1) Having all newly added memory online ASAP is probably what people > > > want for all

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

On Mon 27-02-17 16:43:04, Michal Hocko wrote: > On Mon 27-02-17 12:25:10, Heiko Carstens wrote: > > On Mon, Feb 27, 2017 at 11:02:09AM +0100, Vitaly Kuznetsov wrote: > > > A couple of other thoughts: > > > 1) Having all newly added memory online ASAP is probably what people > > > want for all

Re: regression since 4.8 and newer in select_idle_siblings()

On Tue, 18 Oct 2016 16:02:07 +0200 Mike Galbraith <efa...@gmx.de> wrote: > On Tue, 2016-10-18 at 15:40 +0200, Igor Mammedov wrote: > > kernel crashes at runtime due null pointer dereference at > > select_idle_sibling() > > -> select_idle_cpu() >

Re: regression since 4.8 and newer in select_idle_siblings()

On Tue, 18 Oct 2016 16:02:07 +0200 Mike Galbraith wrote: > On Tue, 2016-10-18 at 15:40 +0200, Igor Mammedov wrote: > > kernel crashes at runtime due null pointer dereference at > > select_idle_sibling() > > -> select_idle_cpu() > > ... >

regression since 4.8 and newer in select_idle_siblings()

kernel crashes at runtime due null pointer dereference at select_idle_sibling() -> select_idle_cpu() ... u64 avg_cost = this_sd->avg_scan_cost; regression bisects to: commit 10e2f1acd0106c05229f94c70a344ce3a2c8008b Author: Peter Zijlstra

regression since 4.8 and newer in select_idle_siblings()

kernel crashes at runtime due null pointer dereference at select_idle_sibling() -> select_idle_cpu() ... u64 avg_cost = this_sd->avg_scan_cost; regression bisects to: commit 10e2f1acd0106c05229f94c70a344ce3a2c8008b Author: Peter Zijlstra sched/core: Rewrite and

[PATCH 1/2] x86/x2apic: fix NULL pointer def during boot

Fixes crash at boot for me. Small nit wrt subj s/def/deref/

[PATCH 1/2] x86/x2apic: fix NULL pointer def during boot

Fixes crash at boot for me. Small nit wrt subj s/def/deref/

[PATCH 1/2] x86/x2apic: fix NULL pointer def during boot

Fixes crash at boot for me. Small nit wrt subj s/def/deref/

[PATCH 1/2] x86/x2apic: fix NULL pointer def during boot

Fixes crash at boot for me. Small nit wrt subj s/def/deref/

Re: [PATCH FIX 4.6+] bcma: add PCI ID for Foxconn's BCM43142 device

9c9a20 ("bcma: claim only 14e4:4365 PCI Dell card with > SoftMAC BCM43142") Reported-by: Igor Mammedov <imamm...@redhat.com> > Signed-off-by: Rafał Miłecki <zaj...@gmail.com> > Cc: Stable <sta...@vger.kernel.org> [4.6+] Tested-by: Igor Mammedov <imamm...@red

Re: [PATCH FIX 4.6+] bcma: add PCI ID for Foxconn's BCM43142 device

ma: claim only 14e4:4365 PCI Dell card with > SoftMAC BCM43142") Reported-by: Igor Mammedov > Signed-off-by: Rafał Miłecki > Cc: Stable [4.6+] Tested-by: Igor Mammedov > --- > drivers/bcma/host_pci.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/bcma/h

Re: [PATCH v4 2/2] KVM: move vcpu id checking to archs

On Fri, 22 Apr 2016 11:25:38 +0200 Greg Kurz wrote: > Hi Radim ! > > On Thu, 21 Apr 2016 19:36:11 +0200 > Radim Krčmář wrote: > > > 2016-04-21 18:45+0200, Greg Kurz: > > > On Thu, 21 Apr 2016 18:00:19 +0200 > > > Radim Krčmář

Re: [PATCH v4 2/2] KVM: move vcpu id checking to archs

On Fri, 22 Apr 2016 11:25:38 +0200 Greg Kurz wrote: > Hi Radim ! > > On Thu, 21 Apr 2016 19:36:11 +0200 > Radim Krčmář wrote: > > > 2016-04-21 18:45+0200, Greg Kurz: > > > On Thu, 21 Apr 2016 18:00:19 +0200 > > > Radim Krčmář wrote: > > >> 2016-04-21 16:20+0200, Greg Kurz: [...] >

Re: [PATCH v2] memory-hotplug: add automatic onlining policy for the newly added memory

On Mon, 04 Jan 2016 11:47:12 +0100 Vitaly Kuznetsov wrote: > Andrew Morton writes: > > > On Tue, 22 Dec 2015 17:32:30 +0100 Vitaly Kuznetsov > > wrote: > > > >> Currently, all newly added memory blocks remain in 'offline' state unless > >> someone onlines them, some linux distributions

Re: [PATCH v2] memory-hotplug: add automatic onlining policy for the newly added memory

On Mon, 04 Jan 2016 11:47:12 +0100 Vitaly Kuznetsov wrote: > Andrew Morton writes: > > > On Tue, 22 Dec 2015 17:32:30 +0100 Vitaly Kuznetsov > > wrote: > > > >> Currently, all newly added memory blocks remain in 'offline'

Re: [PATCH] memory-hotplug: don't BUG() in register_memory_resource()

: Andrew Morton > Cc: Tang Chen > Cc: Naoya Horiguchi > Cc: Xishi Qiu > Cc: Sheng Yong > Cc: David Rientjes > Cc: Zhu Guihua > Cc: Dan Williams > Cc: David Vrabel > Cc: Igor Mammedov > Signed-off-by: Vitaly Kuznetsov > --- > mm/memory_hotplug.c | 17 +

Re: [PATCH] memory-hotplug: don't BUG() in register_memory_resource()

Cc: David Rientjes <rient...@google.com> > Cc: Zhu Guihua <zhugh.f...@cn.fujitsu.com> > Cc: Dan Williams <dan.j.willi...@intel.com> > Cc: David Vrabel <david.vra...@citrix.com> > Cc: Igor Mammedov <imamm...@redhat.com> > Signed-off-by: Vitaly Kuznetsov <vkuzn..

[tip:x86/mm] x86/mm/64: Enable SWIOTLB if system has SRAT memory regions above MAX_DMA32_PFN

Commit-ID: ec941c5ffede4d788b9fc008f9eeca75b9e964f5 Gitweb: http://git.kernel.org/tip/ec941c5ffede4d788b9fc008f9eeca75b9e964f5 Author: Igor Mammedov AuthorDate: Fri, 4 Dec 2015 14:07:06 +0100 Committer: Ingo Molnar CommitDate: Sun, 6 Dec 2015 12:46:31 +0100 x86/mm/64: Enable SWIOTLB

[tip:x86/mm] x86/mm: Introduce max_possible_pfn

Commit-ID: 8dd3303001976aa8583bf20f6b93590c74114308 Gitweb: http://git.kernel.org/tip/8dd3303001976aa8583bf20f6b93590c74114308 Author: Igor Mammedov AuthorDate: Fri, 4 Dec 2015 14:07:05 +0100 Committer: Ingo Molnar CommitDate: Sun, 6 Dec 2015 12:46:31 +0100 x86/mm: Introduce

[tip:x86/mm] x86/mm/64: Enable SWIOTLB if system has SRAT memory regions above MAX_DMA32_PFN

Commit-ID: ec941c5ffede4d788b9fc008f9eeca75b9e964f5 Gitweb: http://git.kernel.org/tip/ec941c5ffede4d788b9fc008f9eeca75b9e964f5 Author: Igor Mammedov <imamm...@redhat.com> AuthorDate: Fri, 4 Dec 2015 14:07:06 +0100 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Sun, 6

[tip:x86/mm] x86/mm: Introduce max_possible_pfn

Commit-ID: 8dd3303001976aa8583bf20f6b93590c74114308 Gitweb: http://git.kernel.org/tip/8dd3303001976aa8583bf20f6b93590c74114308 Author: Igor Mammedov <imamm...@redhat.com> AuthorDate: Fri, 4 Dec 2015 14:07:05 +0100 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Sun, 6

[PATCH v3 0/2] x86: enable SWIOTLB if system has SRAT memory regions above MAX_DMA32_PFN

/2015/11/30/594 Igor Mammedov (2): x86: introduce max_possible_pfn x86_64: enable SWIOTLB if system has SRAT memory regions above MAX_DMA32_PFN arch/x86/kernel/pci-swiotlb.c | 2 +- arch/x86/kernel/setup.c | 2 ++ arch/x86/mm/srat.c| 2 ++ include/linux/bootmem.h | 4

[PATCH v3 1/2] x86: introduce max_possible_pfn

if any present. Signed-off-by: Igor Mammedov --- v3: - make 'max_possible_pfn' 64-bit - simplify condition to oneliner as suggested by Ingo --- arch/x86/kernel/setup.c | 2 ++ arch/x86/mm/srat.c | 2 ++ include/linux/bootmem.h | 4 mm/bootmem.c| 1 + mm/nobootmem.c

[PATCH v3 2/2] x86_64: enable SWIOTLB if system has SRAT memory regions above MAX_DMA32_PFN

if there is hotpluggable memory regions beyond MAX_DMA32_PFN. It fixes KVM guests when they use emulated devices (reproduces with ata_piix, e1000 and usb devices, RHBZ: 1275941, 1275977, 1271527) It also fixes the HyperV, VMWare with emulated devices which are affected by this issue as well. Signed-off-by: Igor

Re: [PATCH v2 2/2] x86_64: enable SWIOTLB if system has SRAT memory regions above MAX_DMA32_PFN

On Fri, 4 Dec 2015 12:49:49 +0100 Ingo Molnar wrote: > > * Igor Mammedov wrote: > > > when memory hotplug enabled system is booted with less > > than 4GB of RAM and then later more RAM is hotplugged > > 32-bit devices stop functioning with following error: > >

Re: [PATCH v2 2/2] x86_64: enable SWIOTLB if system has SRAT memory regions above MAX_DMA32_PFN

On Fri, 4 Dec 2015 12:49:49 +0100 Ingo Molnar wrote: > > * Igor Mammedov wrote: > > > when memory hotplug enabled system is booted with less > > than 4GB of RAM and then later more RAM is hotplugged > > 32-bit devices stop functioning with following error: > >

[PATCH v2 2/2] x86_64: enable SWIOTLB if system has SRAT memory regions above MAX_DMA32_PFN

if there is hotpluggable memory regions beyond MAX_DMA32_PFN. It fixes KVM guests when they use emulated devices (reproduces with ata_piix, e1000 and usb devices, RHBZ: 1275941, 1275977, 1271527) It also fixes the HyperV, VMWare with emulated devices which are affected by this issue as well. Signed-off-by: Igor

[PATCH v2 1/2] x86: introduce max_possible_pfn

table if any present. Signed-off-by: Igor Mammedov --- arch/x86/kernel/setup.c | 2 ++ include/linux/bootmem.h | 4 mm/bootmem.c| 1 + mm/nobootmem.c | 1 + 4 files changed, 8 insertions(+) diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c index 29db25f

[PATCH v2 0/2] x86: enable SWIOTLB if system has SRAT memory regions above MAX_DMA32_PFN

which are affected by this issue as well. ref to v1: https://lkml.org/lkml/2015/11/30/594 Igor Mammedov (2): x86: introduce max_possible_pfn x86_64: enable SWIOTLB if system has SRAT memory regions above MAX_DMA32_PFN arch/x86/kernel/pci-swiotlb.c | 2 +- arch/x86/kernel/setup.c

Re: [PATCH] x86_64: enable SWIOTLB if system has SRAT memory regions above MAX_DMA32_PFN

On Fri, 4 Dec 2015 09:20:50 +0100 Ingo Molnar wrote: > > * Igor Mammedov wrote: > > > diff --git a/arch/x86/include/asm/acpi.h b/arch/x86/include/asm/acpi.h > > index 94c18eb..53d7951 100644 > > --- a/arch/x86/include/asm/acpi.h > > +++ b/arch/x86/includ

[PATCH v2 2/2] x86_64: enable SWIOTLB if system has SRAT memory regions above MAX_DMA32_PFN

if there is hotpluggable memory regions beyond MAX_DMA32_PFN. It fixes KVM guests when they use emulated devices (reproduces with ata_piix, e1000 and usb devices, RHBZ: 1275941, 1275977, 1271527) It also fixes the HyperV, VMWare with emulated devices which are affected by this issue as well. Signed-off-by: Igor

[PATCH v2 1/2] x86: introduce max_possible_pfn

table if any present. Signed-off-by: Igor Mammedov <imamm...@redhat.com> --- arch/x86/kernel/setup.c | 2 ++ include/linux/bootmem.h | 4 mm/bootmem.c| 1 + mm/nobootmem.c | 1 + 4 files changed, 8 insertions(+) diff --git a/arch/x86/kernel/setup.c b/arch/x86/

[PATCH v2 0/2] x86: enable SWIOTLB if system has SRAT memory regions above MAX_DMA32_PFN

which are affected by this issue as well. ref to v1: https://lkml.org/lkml/2015/11/30/594 Igor Mammedov (2): x86: introduce max_possible_pfn x86_64: enable SWIOTLB if system has SRAT memory regions above MAX_DMA32_PFN arch/x86/kernel/pci-swiotlb.c | 2 +- arch/x86/kernel/setup.c

Re: [PATCH v2 2/2] x86_64: enable SWIOTLB if system has SRAT memory regions above MAX_DMA32_PFN

On Fri, 4 Dec 2015 12:49:49 +0100 Ingo Molnar <mi...@kernel.org> wrote: > > * Igor Mammedov <imamm...@redhat.com> wrote: > > > when memory hotplug enabled system is booted with less > > than 4GB of RAM and then later more RAM is hotplugged > > 32-bit

Re: [PATCH] x86_64: enable SWIOTLB if system has SRAT memory regions above MAX_DMA32_PFN

On Fri, 4 Dec 2015 09:20:50 +0100 Ingo Molnar <mi...@kernel.org> wrote: > > * Igor Mammedov <imamm...@redhat.com> wrote: > > > diff --git a/arch/x86/include/asm/acpi.h b/arch/x86/include/asm/acpi.h > > index 94c18eb..53d7951 100644 > > --- a/arch/x8

Re: [PATCH v2 2/2] x86_64: enable SWIOTLB if system has SRAT memory regions above MAX_DMA32_PFN

On Fri, 4 Dec 2015 12:49:49 +0100 Ingo Molnar <mi...@kernel.org> wrote: > > * Igor Mammedov <imamm...@redhat.com> wrote: > > > when memory hotplug enabled system is booted with less > > than 4GB of RAM and then later more RAM is hotplugged > > 32-bit

[PATCH v3 2/2] x86_64: enable SWIOTLB if system has SRAT memory regions above MAX_DMA32_PFN

if there is hotpluggable memory regions beyond MAX_DMA32_PFN. It fixes KVM guests when they use emulated devices (reproduces with ata_piix, e1000 and usb devices, RHBZ: 1275941, 1275977, 1271527) It also fixes the HyperV, VMWare with emulated devices which are affected by this issue as well. Signed-off-by: Igor

[PATCH v3 0/2] x86: enable SWIOTLB if system has SRAT memory regions above MAX_DMA32_PFN

/2015/11/30/594 Igor Mammedov (2): x86: introduce max_possible_pfn x86_64: enable SWIOTLB if system has SRAT memory regions above MAX_DMA32_PFN arch/x86/kernel/pci-swiotlb.c | 2 +- arch/x86/kernel/setup.c | 2 ++ arch/x86/mm/srat.c| 2 ++ include/linux/bootmem.h | 4

[PATCH v3 1/2] x86: introduce max_possible_pfn

if any present. Signed-off-by: Igor Mammedov <imamm...@redhat.com> --- v3: - make 'max_possible_pfn' 64-bit - simplify condition to oneliner as suggested by Ingo --- arch/x86/kernel/setup.c | 2 ++ arch/x86/mm/srat.c | 2 ++ include/linux/bootmem.h | 4 mm/bootmem.c

[PATCH] x86_64: enable SWIOTLB if system has SRAT memory regions above MAX_DMA32_PFN

than 4GB and do not use memory hotplug but still have hotplug regions in SRAT (i.e. broken BIOS that can't disable mem hotplug) can disable memory hotplug with 'acpi_no_memhotplug = 1' to avoid automatic SWIOTLB initialization. Tested on QEMU/KVM and HyperV. Signed-off-by: Igor Mammedov

[PATCH] x86_64: enable SWIOTLB if system has SRAT memory regions above MAX_DMA32_PFN

than 4GB and do not use memory hotplug but still have hotplug regions in SRAT (i.e. broken BIOS that can't disable mem hotplug) can disable memory hotplug with 'acpi_no_memhotplug = 1' to avoid automatic SWIOTLB initialization. Tested on QEMU/KVM and HyperV. Signed-off-by: Igor Mammedov <im

Re: [BUG?] kernel OOPS at kmem_cache_alloc_node() because of smp_processor_id()

oing on at the > > time? A special graphics driver being loaded? That could cause issues. > > > > It seems that the problem was fixed by Igor, right? > https://lkml.org/lkml/2014/3/6/257 That might help. "stuck" CPU14 means that master CPU has given up on the a

Re: [BUG?] kernel OOPS at kmem_cache_alloc_node() because of smp_processor_id()

as handled. set_mtrr()? What was going on at the > > time? A special graphics driver being loaded? That could cause issues. > > > > It seems that the problem was fixed by Igor, right? > https://lkml.org/lkml/2014/3/6/257 That might help. "stuck" CPU14 means th

[PATCH] kvm: svm: reset mmu on VCPU reset

b() time. -- * AMD64 Architecture Programmer’s Manual, Volume 2: System Programming, rev: 3.25 15.19 Paged Real Mode ** Opteron 1216 Signed-off-by: Igor Mammedov --- arch/x86/kvm/svm.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c index fdb8cb6..89173

[PATCH] kvm: svm: reset mmu on VCPU reset

b() time. -- * AMD64 Architecture Programmer’s Manual, Volume 2: System Programming, rev: 3.25 15.19 Paged Real Mode ** Opteron 1216 Signed-off-by: Igor Mammedov <imamm...@redhat.com> --- arch/x86/kvm/svm.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/kvm/svm.c b/arch/x86

Re: [PATCH 2/2] vhost: increase default limit of nregions from 64 to 509

On Thu, 30 Jul 2015 09:33:57 +0300 "Michael S. Tsirkin" wrote: > On Thu, Jul 30, 2015 at 08:26:03AM +0200, Igor Mammedov wrote: > > On Wed, 29 Jul 2015 18:28:26 +0300 > > "Michael S. Tsirkin" wrote: > > > > > On Wed, Jul 29, 2015 at 04:29:23P

Re: [PATCH 2/2] vhost: increase default limit of nregions from 64 to 509

On Thu, 30 Jul 2015 09:33:57 +0300 "Michael S. Tsirkin" wrote: > On Thu, Jul 30, 2015 at 08:26:03AM +0200, Igor Mammedov wrote: > > On Wed, 29 Jul 2015 18:28:26 +0300 > > "Michael S. Tsirkin" wrote: > > > > > On Wed, Jul 29, 2015 at 04:29:23P

Re: [PATCH 2/2] vhost: increase default limit of nregions from 64 to 509

On Wed, 29 Jul 2015 18:28:26 +0300 "Michael S. Tsirkin" wrote: > On Wed, Jul 29, 2015 at 04:29:23PM +0200, Igor Mammedov wrote: > > although now there is vhost module max_mem_regions option > > to set custom limit it doesn't help for default setups, > > since it

  1   2   3   4   5   >