RE: [PATCH v2] Linux VM workaround for Knights Landing A/D leak

From: Nadav Amit [mailto:nadav.a...@gmail.com] Sent: Tuesday, June 14, 2016 8:38 PM >> +pte_t pte = ptep_get_and_clear(mm, addr, ptep); >> + >> +if (boot_cpu_has_bug(X86_BUG_PTE_LEAK)) >> +fix_pte_leak(mm, addr, ptep); >> +return pte; >> } > > I missed it on the previous

RE: [PATCH v2] Linux VM workaround for Knights Landing A/D leak

From: Nadav Amit [mailto:nadav.a...@gmail.com] Sent: Tuesday, June 14, 2016 8:38 PM >> +pte_t pte = ptep_get_and_clear(mm, addr, ptep); >> + >> +if (boot_cpu_has_bug(X86_BUG_PTE_LEAK)) >> +fix_pte_leak(mm, addr, ptep); >> +return pte; >> } > > I missed it on the previous

RE: [PATCH v2] Linux VM workaround for Knights Landing A/D leak

From: Borislav Petkov [mailto:b...@alien8.de] Sent: Tuesday, June 14, 2016 8:10 PM >> +if (boot_cpu_has_bug(X86_BUG_PTE_LEAK)) > > static_cpu_has_bug() >> +if (c->x86_model == 87) { > > That should be INTEL_FAM6_XEON_PHI_KNL, AFAICT. >> +static bool printed; >> + >> +

RE: [PATCH v2] Linux VM workaround for Knights Landing A/D leak

From: Borislav Petkov [mailto:b...@alien8.de] Sent: Tuesday, June 14, 2016 8:10 PM >> +if (boot_cpu_has_bug(X86_BUG_PTE_LEAK)) > > static_cpu_has_bug() >> +if (c->x86_model == 87) { > > That should be INTEL_FAM6_XEON_PHI_KNL, AFAICT. >> +static bool printed; >> + >> +

RE: [PATCH] Linux VM workaround for Knights Landing A/D leak

From: Dave Hansen [mailto:dave.han...@linux.intel.com] Sent: Tuesday, June 14, 2016 7:20 PM >> diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h ... >> +extern void fix_pte_leak(struct mm_struct *mm, unsigned long addr, >> + pte_t *ptep); > Doesn't

RE: [PATCH] Linux VM workaround for Knights Landing A/D leak

From: Dave Hansen [mailto:dave.han...@linux.intel.com] Sent: Tuesday, June 14, 2016 7:20 PM >> diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h ... >> +extern void fix_pte_leak(struct mm_struct *mm, unsigned long addr, >> + pte_t *ptep); > Doesn't

RE: [PATCH] Linux VM workaround for Knights Landing A/D leak

From: Nadav Amit [mailto:nadav.a...@gmail.com] Sent: Tuesday, June 14, 2016 6:48 PM > Lukasz Anaczkowski wrote: >> From: Andi Kleen >> +void fix_pte_leak(struct mm_struct *mm, unsigned long addr, pte_t *ptep) >> +{ > Here there should be a

RE: [PATCH] Linux VM workaround for Knights Landing A/D leak

From: Nadav Amit [mailto:nadav.a...@gmail.com] Sent: Tuesday, June 14, 2016 6:48 PM > Lukasz Anaczkowski wrote: >> From: Andi Kleen >> +void fix_pte_leak(struct mm_struct *mm, unsigned long addr, pte_t *ptep) >> +{ > Here there should be a call to smp_mb__after_atomic() to synchronize with >

RE: [PATCH 1/4] EDAC: add DDR4 flag

-Original Message- From: Borislav Petkov [mailto:b...@alien8.de] Sent: Wednesday, December 2, 2015 8:28 PM To: Chrzaniuk, Hubert Cc: Anaczkowski, Lukasz ; mche...@osg.samsung.com; dougthomp...@xmission.com; linux-e...@vger.kernel.org; linux-kernel@vger.kernel.org; Snow, Jim M Subject

RE: [PATCH 1/4] EDAC: add DDR4 flag

-Original Message- From: Borislav Petkov [mailto:b...@alien8.de] Sent: Wednesday, December 2, 2015 8:28 PM To: Chrzaniuk, Hubert <hubert.chrzan...@intel.com> Cc: Anaczkowski, Lukasz <lukasz.anaczkow...@intel.com>; mche...@osg.samsung.com; dougthomp...@xmission.

RE: [PATCH] Added multiplier for APERF and MPERF counters

From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] Sent: Thursday, September 17, 2015 7:05 PM > Please *always* send PM-related patches to linux...@vger.kernel.org (CCed > now). Ok, thanks for noticing. I've addressed my patch based on output of ./scripts/get_maintainer.pl and gave me output

RE: [PATCH] Added multiplier for APERF and MPERF counters

From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] Sent: Thursday, September 17, 2015 7:05 PM > Please *always* send PM-related patches to linux...@vger.kernel.org (CCed > now). Ok, thanks for noticing. I've addressed my patch based on output of ./scripts/get_maintainer.pl and gave me output

RE: [PATCH 2/2] x86, acpi: Handle apic/x2apic entries in MADT in correct order

-Original Message- From: Lorenzo Pieralisi [mailto:lorenzo.pieral...@arm.com] Sent: Wednesday, September 9, 2015 3:56 PM > On Wed, Sep 09, 2015 at 10:30:18AM +0100, Lukasz Anaczkowski wrote: > > () it's hard to predict how cores and threads are enumerated > So ? Why would the logical

RE: [PATCH 0/4] Fix how CPUs are enumerated when there's more than 255 CPUs

From: Marc Zyngier [mailto:marc.zyng...@arm.com] Sent: Tuesday, September 8, 2015 6:28 PM > In my view, this makes the change a lot more palatable, and it can fit in > exactly two patches: > > 1) add the acpi_subtable_proc stuff with the compatibility helpers > 2) change

RE: [PATCH 0/4] Fix how CPUs are enumerated when there's more than 255 CPUs

From: Marc Zyngier [mailto:marc.zyng...@arm.com] Sent: Tuesday, September 8, 2015 6:28 PM > In my view, this makes the change a lot more palatable, and it can fit in > exactly two patches: > > 1) add the acpi_subtable_proc stuff with the compatibility helpers > 2) change

RE: [PATCH 2/2] x86, acpi: Handle apic/x2apic entries in MADT in correct order

-Original Message- From: Lorenzo Pieralisi [mailto:lorenzo.pieral...@arm.com] Sent: Wednesday, September 9, 2015 3:56 PM > On Wed, Sep 09, 2015 at 10:30:18AM +0100, Lukasz Anaczkowski wrote: > > () it's hard to predict how cores and threads are enumerated > So ? Why would the logical

RE: [PATCH] x86, arm64, acpi: Handle lapic/x2apic entries in MADT

From: Tomasz Nowicki [mailto:tomasz.nowi...@linaro.org] Sent: Tuesday, September 1, 2015 3:37 PM > On 01.09.2015 14:07, Anaczkowski, Lukasz wrote: >> From: Tomasz Nowicki [mailto:tomasz.nowi...@linaro.org] >> Sent: Tuesday, September 1, 2015 10:03 AM >>> >>>>

RE: [PATCH] x86, arm64, acpi: Handle lapic/x2apic entries in MADT

From: Tomasz Nowicki [mailto:tomasz.nowi...@linaro.org] Sent: Tuesday, September 1, 2015 3:37 PM > On 01.09.2015 14:07, Anaczkowski, Lukasz wrote: >> From: Tomasz Nowicki [mailto:tomasz.nowi...@linaro.org] >> Sent: Tuesday, September 1, 2015 10:03 AM >>> >>>>

RE: [PATCH] x86, arm64, acpi: Handle lapic/x2apic entries in MADT

From: Tomasz Nowicki [mailto:tomasz.nowi...@linaro.org] Sent: Tuesday, September 1, 2015 10:03 AM >> To fix this, each LAPIC/X2APIC entry from MADT table needs to be >> handled at the same time when processing it, thus adding >> acpi_subtable_proc structure which stores >> () ACPI table id >>

RE: [PATCH] x86, arm64, acpi: Handle lapic/x2apic entries in MADT

From: Tomasz Nowicki [mailto:tomasz.nowi...@linaro.org] Sent: Tuesday, September 1, 2015 10:03 AM >> To fix this, each LAPIC/X2APIC entry from MADT table needs to be >> handled at the same time when processing it, thus adding >> acpi_subtable_proc structure which stores >> () ACPI table id >>

RE: [PATCH] x86, acpi: Handle lapic/x2apic entries in MADT

On Monday, August 3, 2015 8:26 PM Lukasz Anaczkowski wrote: > v2: Fixed ARM64 syntax error Hi Marc, Does this patch look ok now? Thanks, Lukasz -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info

RE: [PATCH] x86, acpi: Handle lapic/x2apic entries in MADT

On Monday, August 3, 2015 8:26 PM Lukasz Anaczkowski lukasz.anaczkow...@intel.com wrote: v2: Fixed ARM64 syntax error Hi Marc, Does this patch look ok now? Thanks, Lukasz -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to

RE: [PATCH] x86, acpi: Handle xapic/x2apic entries in MADT

> I have some concerns here about "maxcpus" and "nox2apic" kernel parameters. > Say "maxcpus=72 nox2apic" is specified, user may get less than 72 CPUs with > you patch applied. Original code will try to only all xapic CPUs before > trying x2apic CPUs, so "maxcpus" doesn't conflict with

RE: [PATCH] x86, acpi: Handle xapic/x2apic entries in MADT

I have some concerns here about maxcpus and nox2apic kernel parameters. Say maxcpus=72 nox2apic is specified, user may get less than 72 CPUs with you patch applied. Original code will try to only all xapic CPUs before trying x2apic CPUs, so maxcpus doesn't conflict with nox2apic. HI Gerry,

RE: [PATCH 2/3] sb_edac: virtualize several hard-coded functions

> From: Aristeu Rozanski [mailto:a...@redhat.com] > the only reason these exist is for when there's a difference between memory > controllers: > > pvt->info.get_memory_type = get_memory_type; > > pvt->info.get_memory_type = get_memory_type; > >

RE: [PATCH 2/3] sb_edac: virtualize several hard-coded functions

From: Aristeu Rozanski [mailto:a...@redhat.com] the only reason these exist is for when there's a difference between memory controllers: pvt-info.get_memory_type = get_memory_type; pvt-info.get_memory_type = get_memory_type; pvt-info.get_memory_type