Changed email address

Hi guys, in case there are any inquiries regarding code of mine (e.g. triggered by git annotate or commit messages), feel free to contact me via my private address: o...@andrep.de My AMD email address is no longer valid. Regards, André Przywara -- To unsubscribe from this list: send the line

[PATCH] x86/amd: disable way access filter on affected CPUs

From: Andre Przywara andre.przyw...@amd.com The Way Access Filter in recent AMD CPUs may hurt the performance of some workloads, caused by aliasing issues in the L1 cache. This patch disables it on the affected CPUs. The issue is similar to that one of last year: http://lkml.indiana.edu

[PATCH] x86/amd: disable way access filter on affected CPUs

The WAF may hurt the performance of some workloads, caused by aliasing issues in the L1 cache. Disable it on the affected CPUs. Signed-off-by: Andre Przywara andre.przyw...@amd.com --- arch/x86/kernel/cpu/amd.c | 14 ++ 1 file changed, 14 insertions(+) diff --git a/arch/x86/kernel

Re: [PATCH] x86/amd: disable way access filter on affected CPUs

On 10/24/2012 12:46 PM, Ingo Molnar wrote: * Andre Przywara andre.przyw...@amd.com wrote: The WAF may hurt the performance of some workloads, caused by aliasing issues in the L1 cache. Disable it on the affected CPUs. Signed-off-by: Andre Przywara andre.przyw...@amd.com --- arch/x86/kernel

[PATCH] x86/perf: Fix virtualization sanity check

and read-back that modified number from the MSR. Signed-off-by: Andre Przywara andre.przyw...@amd.com --- arch/x86/kernel/cpu/perf_event.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/arch/x86/kernel/cpu/perf_event.c b/arch/x86/kernel/cpu/perf_event.c index 915b876

[PATCH] x86/perf: Fix virtualization sanity check

and read-back that modified number from the MSR. Signed-off-by: Andre Przywara andre.przyw...@amd.com --- arch/x86/kernel/cpu/perf_event.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/arch/x86/kernel/cpu/perf_event.c b/arch/x86/kernel/cpu/perf_event.c index 915b876

Re: [PATCH] x86/perf: Fix virtualization sanity check

On 10/09/2012 05:51 PM, Konrad Rzeszutek Wilk wrote: On Tue, Oct 09, 2012 at 05:38:34PM +0200, Andre Przywara wrote: In check_hw_exists() we try to detect non-emulated MSR accesses by writing an arbitrary value into one of the PMU registers and check if it's value after a readout is still

Re: linux-next: Tree for Sept 6 (does not boot on AMD64)

problems with this patchset? Or are you only wondering about the new config switch? Thanks for testing! Andre. -- Andre Przywara AMD-Operating System Research Center (OSRC), Dresden, Germany -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord

Re: [PATCH 2/8 v2] acpi-cpufreq: Add quirk to disable _PSD usage on all AMD CPUs

On 09/15/2012 01:20 PM, Konrad Rzeszutek Wilk wrote: On Sep 4, 2012 4:26 AM, Andre Przywara andre.przyw...@amd.com mailto:andre.przyw...@amd.com wrote: To workaround some Windows specific behavior, the ACPI _PSD table on AMD desktop boards advertises all cores as dependent, meaning

[PATCH 0/8] acpi-cpufreq: Move modern AMD cpufreq support to acpi-cpufreq

mostly reworked and documentation for it has been added. Also there was a need for (yet another) BIOS quirk on AMD desktop boards. Signed-off-by: Andre Przywara andre.przyw...@amd.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord

[PATCH 2/8] acpi-cpufreq: Add quirk to disable _PSD usage on all AMD CPUs

. Signed-off-by: Andre Przywara andre.przyw...@amd.com --- drivers/cpufreq/acpi-cpufreq.c |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c index 067a61f..ea949b8 100644 --- a/drivers/cpufreq/acpi-cpufreq.c

[PATCH 4/8] ACPI: Add fixups for AMD P-state figures

From: Matthew Garrett m...@redhat.com Some AMD systems may round the frequencies in ACPI tables to 100MHz boundaries. We can obtain the real frequencies from MSRs, so add a quirk to fix these frequencies up on AMD systems. Signed-off-by: Matthew Garrett m...@redhat.com Signed-off-by: Andre

[PATCH 3/8] cpufreq: Add compatibility hack to powernow-k8

without any cpufreq support after the transition. Signed-off-by: Matthew Garrett m...@redhat.com Signed-off-by: Andre Przywara andre.przyw...@amd.com --- drivers/cpufreq/powernow-k8.c |6 +- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/drivers/cpufreq/powernow-k8.c b

[PATCH 5/8] acpi-cpufreq: Add support for disabling dynamic overclocking

for compatibility reasons on AMD CPUs. Per-CPU boost switching is possible, but not trivial and is thus postponed to a later patch series. Signed-off-by: Andre Przywara andre.przyw...@amd.com --- drivers/cpufreq/acpi-cpufreq.c | 177 1 files changed, 177

[PATCH 1/8] acpi-cpufreq: Add support for modern AMD CPUs

with hardware P-state control to acpi-cpufreq. Signed-off-by: Matthew Garrett m...@redhat.com Signed-off-by: Andre Przywara andre.przyw...@amd.com --- arch/x86/include/asm/msr-index.h |2 + drivers/cpufreq/acpi-cpufreq.c | 43 - 2 files changed, 39 insertions(+), 6

[PATCH 8/8] Documentation: Add documentation for boost control switch

The new acpi-cpufreq driver supports a system global control switch to disable the frequency boosting feature of some (x86) CPUs. Provide documentation about the rationale and the usage. Signed-off-by: Andre Przywara andre.przyw...@amd.com --- Documentation/ABI/testing/sysfs-devices-system-cpu

[PATCH 7/8] cpufreq: Remove support for hardware P-state chips from powernow-k8

From: Matthew Garrett m...@redhat.com These chips are now supported by acpi-cpufreq, so we can delete all the code handling them. Signed-off-by: Matthew Garrett m...@redhat.com Signed-off-by: Andre Przywara andre.przyw...@amd.com --- drivers/cpufreq/Makefile |2 +- drivers/cpufreq

[PATCH 6/8] acpi-cpufreq: Add compatibility for legacy AMD cpb sysfs knob

I'd like to consider this feature obsolete. Lets keep it around for some kernel versions and then phase it out. Signed-off-by: Andre Przywara andre.przyw...@amd.com --- drivers/cpufreq/Kconfig.x86| 12 ++ drivers/cpufreq/acpi-cpufreq.c | 46

[PATCH 0/8 v2] acpi-cpufreq: Move modern AMD cpufreq support to acpi-cpufreq

Hi, now the second, revised version of the patch set. I now tested loading both drivers after each other in several combinations, after two bug fixes this now works as expected. I added a patch to move messages from powernow-k8 after the initialization phase, so it remains silent if driver

[PATCH 5/8 v2] ACPI: Add fixups for AMD P-state figures

From: Matthew Garrett m...@redhat.com Some AMD systems may round the frequencies in ACPI tables to 100MHz boundaries. We can obtain the real frequencies from MSRs, so add a quirk to fix these frequencies up on AMD systems. Signed-off-by: Matthew Garrett m...@redhat.com Signed-off-by: Andre

[PATCH 3/8 v2] cpufreq: Add warning message to powernow-k8

cpufreq modules are often loaded from init scripts that assume that all recent AMD systems will use powernow-k8. To inform the user of the change of support and ease the transition to acpi-cpufreq, emit a warning message. Signed-off-by: Andre Przywara andre.przyw...@amd.com --- drivers/cpufreq

[PATCH 2/8 v2] acpi-cpufreq: Add quirk to disable _PSD usage on all AMD CPUs

. Signed-off-by: Andre Przywara andre.przyw...@amd.com --- drivers/cpufreq/acpi-cpufreq.c | 10 ++ 1 file changed, 10 insertions(+) diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c index 067a61f..70e7173 100644 --- a/drivers/cpufreq/acpi-cpufreq.c +++ b/drivers

[PATCH 8/8 v2] cpufreq: Remove support for hardware P-state chips from powernow-k8

without any cpufreq support after the transition. Signed-off-by: Matthew Garrett m...@redhat.com Signed-off-by: Andre Przywara andre.przyw...@amd.com --- drivers/cpufreq/Makefile | 2 +- drivers/cpufreq/powernow-k8.c | 392 +++--- drivers/cpufreq/powernow

[PATCH 7/8 v2] acpi-cpufreq: Add compatibility for legacy AMD cpb sysfs knob

I'd like to consider this feature obsolete. Lets keep it around for some kernel versions and then phase it out. Signed-off-by: Andre Przywara andre.przyw...@amd.com --- drivers/cpufreq/Kconfig.x86| 12 +++ drivers/cpufreq/acpi-cpufreq.c | 46

[PATCH 6/8 v2] acpi-cpufreq: Add support for disabling dynamic overclocking

patch will re-introduce the cpb knob for compatibility reasons on AMD CPUs. Per-CPU boost switching is possible, but not trivial and is thus postponed to a later patch series. Signed-off-by: Andre Przywara andre.przyw...@amd.com --- Documentation/ABI/testing/sysfs-devices-system-cpu | 11

[PATCH 1/8 v2] acpi-cpufreq: Add support for modern AMD CPUs

with hardware P-state control to acpi-cpufreq. Signed-off-by: Matthew Garrett m...@redhat.com Signed-off-by: Andre Przywara andre.przyw...@amd.com --- arch/x86/include/asm/msr-index.h | 2 ++ drivers/cpufreq/Kconfig.x86 | 3 ++- drivers/cpufreq/acpi-cpufreq.c | 43

[PATCH 4/8 v2] powernow-k8: delay info messages until initialization has succeeded

not succeed. Signed-off-by: Andre Przywara andre.przyw...@amd.com --- drivers/cpufreq/powernow-k8.c | 24 ++-- 1 file changed, 14 insertions(+), 10 deletions(-) diff --git a/drivers/cpufreq/powernow-k8.c b/drivers/cpufreq/powernow-k8.c index 16c7fb6..8ff0621 100644

Re: [PATCH 0/8 v2] acpi-cpufreq: Move modern AMD cpufreq support to acpi-cpufreq

On 09/05/2012 04:25 PM, Thomas Renninger wrote: On Wednesday, September 05, 2012 03:46:22 PM Rafael J. Wysocki wrote: On Tuesday, September 04, 2012, Andre Przywara wrote: Hi, I have applied the whole series to the linux-next branch of the linux-pm.git Thanks! tree, but I'm quite unsure

Re: [PATCH 7/8] cpufreq: Remove support for hardware P-state chips from powernow-k8

On 08/22/2012 03:00 AM, Thomas Renninger wrote: On Monday 20 August 2012 22:49:16 Rafael J. Wysocki wrote: On Monday, August 20, 2012, Andre Przywara wrote: On 08/05/2012 11:33 PM, Rafael J. Wysocki wrote: On Thursday, July 26, 2012, Andre Przywara wrote: ... If you insist, I can keep

Re: [PATCH 7/8] cpufreq: Remove support for hardware P-state chips from powernow-k8

On 08/05/2012 11:33 PM, Rafael J. Wysocki wrote: On Thursday, July 26, 2012, Andre Przywara wrote: From: Matthew Garrett m...@redhat.com These chips are now supported by acpi-cpufreq, so we can delete all the code handling them. Signed-off-by: Matthew Garrett m...@redhat.com Signed-off

Re: [PATCH 2/2] cpu: intel, amd: mask cleared cpuid features

. Regards, Andre. -- Andre Przywara AMD-Operating System Research Center (OSRC), Dresden, Germany -- 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 at http://vger.kernel.org/majordomo-info.html Please

Re: [PATCH 2/2] cpu: intel, amd: mask cleared cpuid features

see that you do already massive sysfs filtering and also /proc/pid filtering, so this maybe an option? This approach does not need any kernel support (except for the /proc/cpuinfo filtering). Does this address the issues you have? Regards, Andre. -- Andre Przywara AMD-Operating System

Re: [PATCH 2/2] cpu: intel, amd: mask cleared cpuid features

to write the same reply yesterday, but followed the hint in Alan's previous mail: # mount --bind /dev/shm/faked_cpuinfo /somepath/proc/cpuinfo I checked it, it works even with chroots and is not visible from within. Regards, Andre. -- Andre Przywara AMD-Operating System Research Center (OSRC

Re: [PATCH 2/2] cpu: intel, amd: mask cleared cpuid features

On 07/25/2012 01:02 PM, Vladimir Davydov wrote: On 07/25/2012 02:58 PM, Andre Przywara wrote: On 07/25/2012 12:31 PM, Vladimir Davydov wrote: On 07/24/2012 04:44 PM, Alan Cox wrote: This approach does not need any kernel support (except for the /proc/cpuinfo filtering). Does this address

Re: [PATCH 19/19] Documentation: ACPI for ARM64

On 28/07/14 11:46, Arnd Bergmann wrote: On Monday 28 July 2014 10:23:57 Graeme Gregory wrote: The PL011 UART is the use-case I keep hitting, that IP block has a variable input clock on pretty much everything I have seen in the wild. Ok, I see. What does ACPI-5.1 say about pl011?

BPF crash with 3.18-rc1 on arm64 Juno hardware

Hi, I see a crash with 3.18-rc1 on a Juno board related to bpf_jit (see dump below). Userland tries to carry on afterwards, but eventually hangs in RCU stalls. The kernel has just CONFIG_BPF_JIT enabled, I guess Ubuntu enables this automatically if detected. The backtrace doesn't make too much

Re: BPF crash with 3.18-rc1 on arm64 Juno hardware

Hi, On 24/10/14 11:31, Catalin Marinas wrote: On Thu, Oct 23, 2014 at 06:23:49PM +0100, Z Lim wrote: On Thu, Oct 23, 2014 at 10:00 AM, Andre Przywara andre.przyw...@arm.com wrote: I see a crash with 3.18-rc1 on a Juno board related to bpf_jit (see dump below). Userland tries to carry

Re: [RFC PATCH 1/1] drivers: introduce ARM SBSA generic UART driver

Hi Arnd, On 02/09/14 20:51, Arnd Bergmann wrote: On Saturday 30 August 2014 00:10:39 Andre Przywara wrote: On 08/29/2014 07:59 PM, Arnd Bergmann wrote: On Friday 29 August 2014 17:13:23 Andre Przywara wrote: The ARM Server Base System Architecture (SBSA) describes a generic UART which all

Re: [RFC PATCH 1/1] drivers: introduce ARM SBSA generic UART driver

On 02/09/14 20:34, Arnd Bergmann wrote: On Tuesday 02 September 2014 12:38:23 Rob Herring wrote: On Tue, Sep 2, 2014 at 8:48 AM, Arnd Bergmann a...@arndb.de wrote: On Tuesday 02 September 2014 08:20:53 Rob Herring wrote: This alone is not okay. There is no such implementation of hardware.

Re: [RFC PATCH 1/1] drivers: introduce ARM SBSA generic UART driver

Hi Rob, On 02/09/14 18:38, Rob Herring wrote: On Tue, Sep 2, 2014 at 8:48 AM, Arnd Bergmann a...@arndb.de wrote: On Tuesday 02 September 2014 08:20:53 Rob Herring wrote: This alone is not okay. There is no such implementation of hardware. But the SBSA explicitly allows this. I don't know of

Re: [RFC PATCH 1/1] drivers: introduce ARM SBSA generic UART driver

Hi Rob, thanks for looking at this. On 02/09/14 04:06, Rob Herring wrote: On Fri, Aug 29, 2014 at 11:13 AM, Andre Przywara andre.przyw...@arm.com wrote: The ARM Server Base System Architecture (SBSA) describes a generic UART which all compliant level 1 systems should implement

Re: [PATCH v4 0/3] irqfd support for arm/arm64

Hi, On 24/11/14 10:10, Eric Auger wrote: On 11/24/2014 10:47 AM, Christoffer Dall wrote: On Sun, Nov 23, 2014 at 06:56:57PM +0100, Eric Auger wrote: This patch series enables irqfd on arm and arm64. Irqfd framework enables to inject a virtual IRQ into a guest upon an eventfd trigger.

Re: [RFC PATCH 1/4] ARM: KVM: on unhandled IO mem abort, route the call to the KVM MMIO bus

Hi Nikolay, On 13/11/14 11:37, Marc Zyngier wrote: [fixing Andre's email address] On 13/11/14 11:20, Christoffer Dall wrote: On Thu, Nov 13, 2014 at 12:45:42PM +0200, Nikolay Nikolaev wrote: [...] Going through the vgic_handle_mmio we see that it will require large refactoring: -

Re: [RFC PATCH 1/4] ARM: KVM: on unhandled IO mem abort, route the call to the KVM MMIO bus

Hi Nikolay, On 13/11/14 12:29, Nikolay Nikolaev wrote: On Thu, Nov 13, 2014 at 1:52 PM, Andre Przywara andre.przyw...@arm.com wrote: Hi Nikolay, On 13/11/14 11:37, Marc Zyngier wrote: [fixing Andre's email address] On 13/11/14 11:20, Christoffer Dall wrote: On Thu, Nov 13, 2014 at 12:45

Re: [RFC PATCH 1/4] ARM: KVM: on unhandled IO mem abort, route the call to the KVM MMIO bus

On 13/11/14 15:02, Nikolay Nikolaev wrote: On Thu, Nov 13, 2014 at 4:23 PM, Eric Auger eric.au...@linaro.org wrote: On 11/13/2014 03:16 PM, Eric Auger wrote: On 11/13/2014 11:45 AM, Nikolay Nikolaev wrote: On Mon, Nov 10, 2014 at 6:27 PM, Christoffer Dall christoffer.d...@linaro.org wrote:

[PATCH 5/6] arm64: add Cortex-A57 erratum 832075 workaround

The ARM erratum 832075 applies to certain revisions of Cortex-A57, one of the workarounds is to change device loads into using load-aquire semantics. This is achieved using the alternatives framework. Signed-off-by: Andre Przywara andre.przyw...@arm.com --- arch/arm64/include/asm/cpufeature.h

[PATCH 2/6] arm64: add alternative runtime patching

With a blatant copy of some x86 bits we introduce the alternative runtime patching framework to arm64. This is quite basic for now and we only provide the functions we need at this time. This is connected to the newly introduced feature bits. Signed-off-by: Andre Przywara andre.przyw...@arm.com

[PATCH 3/6] arm64: detect silicon revisions and set cap bits accordingly

-by: Andre Przywara andre.przyw...@arm.com --- arch/arm64/include/asm/cpufeature.h |2 ++ arch/arm64/kernel/Makefile |2 +- arch/arm64/kernel/cpu_errata.c | 59 +++ arch/arm64/kernel/cpuinfo.c |3 ++ 4 files changed, 65 insertions

[PATCH 0/6] arm64: alternatives runtime patching

means rather than provoking random hacks. The code can be found also in the alternatives/v1 branch of: http://www.linux-arm.org/git?p=linux-ap.git git://linux-arm.org/linux-ap.git Please review and comment! Cheers, Andre. Andre Przywara (6): arm64: add cpu_capabilities bitmap arm64: add

[PATCH 6/6] arm64: protect alternatives workarounds with Kconfig options

all of them are enabled. Normal users or distribution kernels shouldn't bother to deselect any bugs here, since the alternatives framework will take care of patching them in only if needed. Signed-off-by: Andre Przywara andre.przyw...@arm.com --- arch/arm64/Kconfig | 107

[PATCH 1/6] arm64: add cpu_capabilities bitmap

accessors). Signed-off-by: Andre Przywara andre.przyw...@arm.com --- arch/arm64/include/asm/cpufeature.h | 20 arch/arm64/kernel/setup.c |3 +++ 2 files changed, 23 insertions(+) diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm

[PATCH 4/6] arm64: add Cortex-A53 cache errata workaround

at runtime. Signed-off-by: Andre Przywara andre.przyw...@arm.com --- arch/arm64/include/asm/alternative-asm.h | 13 arch/arm64/include/asm/cpufeature.h |8 +++- arch/arm64/include/asm/cputype.h |5 + arch/arm64/kernel/cpu_errata.c | 32

[PATCH] arm64: add module support for alternatives fixups

the patching in the module's code. Signed-off-by: Andre Przywara andre.przyw...@arm.com --- Hi Will, so this patch make alternatives patching now work with modules. This required some changes in the core alternatives code, so it would have looked better when folded in (but it's already too late

[PATCH] arm/mm: fix compiler warning in pmdp_invalidate() (in -next)

function to get rid of this warning. Signed-off-by: Andre Przywara andre.przyw...@arm.com --- Hi Andrew, Mel mentioned that I should send that simple fix below to you to merge it with his original mmotm patch: mm-convert-p_mknonnuma-and-remaining-page-table-manipulations.patch The commit message above

stand-alone kvmtool

Hi, as I found it increasingly inconvenient to use kvmtool[1] as part of a Linux repository, I decided to give it a go and make it a stand-alone project. So I filtered all the respective commits, adjusted the paths in there (while keeping authorship and commit date, of course) and then added the

[PATCH] arm/mm: fix compiler warning in pmdp_invalidate() (in -next)

function to get rid of this warning. Signed-off-by: Andre Przywara andre.przyw...@arm.com --- arch/arm/include/asm/pgtable-3level.h |5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/arch/arm/include/asm/pgtable-3level.h b/arch/arm/include/asm/pgtable-3level.h index 370684d

Re: stand-alone kvmtool

Ciao Claudio, On 13/02/15 14:30, Claudio Fontana wrote: Hello Andre, On 13.02.2015 11:39, Andre Przywara wrote: Hi, as I found it increasingly inconvenient to use kvmtool[1] as part of a Linux repository, I decided to give it a go and make it a stand-alone project. So I filtered all

Re: [PATCH RFT v2] x86: move cacheinfo sysfs to generic cacheinfo infrastructure

On Tue, 24 Feb 2015 18:57:49 +0100, Borislav Petkov wrote: On Mon, Feb 23, 2015 at 06:14:25PM +, Sudeep Holla wrote: - Rebased on v4.0-rc1 - Fixed lockdep warning reported by Borislav You probably have fixed the lockdep splat but not the NULL pointer dereference which was there in the

Re: stand-alone kvmtool

Hi Will, On 18/02/15 15:50, Will Deacon wrote: Hi Andre, Thanks for doing this. Since it looks unlikely that kvmtool will ever be merged back into the kernel tree, it makes sense to cut the dependency in my opinion. On Fri, Feb 13, 2015 at 10:39:33AM +, Andre Przywara wrote: as I

Re: stand-alone kvmtool

Hi Sasha, thanks for taking a look! On 19/02/15 10:56, Sasha Levin wrote: On 02/13/2015 05:39 AM, Andre Przywara wrote: Hi, as I found it increasingly inconvenient to use kvmtool[1] as part of a Linux repository, I decided to give it a go and make it a stand-alone project. So I filtered

[PATCH] fs/nfs: fix new compiler warning about boolean in switch

) { ^ This code was obviously using switch to make use of the fall-through semantics (without the usual comment, though). Rewrite that code using if statements to avoid the warning and make the code a bit more readable on the way. Signed-off-by: Andre Przywara andre.przyw...@arm.com --- fs/nfs

[PATCH] arm: cmpxchg: update macro to prevent compiler warning

)))__cmpxchg_mb((ptr), \ ^ kernel/acct.c:174:2: note: in expansion of macro 'cmpxchg' cmpxchg(acct-ns-bacct, pin, NULL); ^ Rearrange the macro along the lines of a similar patch for arm64 60010e508111 (arm64: cmpxchg: update macros to prevent warnings) to fix the warning. Signed-off-by: Andre Przywara

Re: [PATCH 1/7] KVM: api: add kvm_irq_routing_extended_msi

Hi, On 03/07/15 10:05, Andre Przywara wrote: Hi Pavel, On 02/07/15 08:26, Pavel Fedin wrote: Hello! -Original Message- From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On Behalf Of Eric Auger Sent: Monday, June 29, 2015 6:37 PM To: eric.au...@st.com; eric.au

Re: [PATCH 1/7] KVM: api: add kvm_irq_routing_extended_msi

Hi Eric, On 02/07/15 15:49, Eric Auger wrote: Hi Pavel, On 07/02/2015 09:26 AM, Pavel Fedin wrote: Hello! -Original Message- From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On Behalf Of Eric Auger Sent: Monday, June 29, 2015 6:37 PM To: eric.au...@st.com;

Re: [PATCH 1/7] KVM: api: add kvm_irq_routing_extended_msi

Hi Christoffer, On 06/07/15 10:30, Christoffer Dall wrote: On Mon, Jul 06, 2015 at 09:30:20AM +0100, Andre Przywara wrote: Hi Pavel, On 06/07/15 07:42, Pavel Fedin wrote: Hello! I like this approach, but it runs into problems: As you read above the current documentation says

Re: [PATCH 1/7] KVM: api: add kvm_irq_routing_extended_msi

Hi Pavel, On 06/07/15 07:42, Pavel Fedin wrote: Hello! I like this approach, but it runs into problems: As you read above the current documentation says that the flags field must be zero and the current KVM_SET_GSI_ROUTING handler bails out if it isn't. So userland would need to know

Re: [PATCH 1/7] KVM: api: add kvm_irq_routing_extended_msi

Hi Paolo, thanks for looking at this! On 06/07/15 12:07, Paolo Bonzini wrote: On 06/07/2015 12:37, Christoffer Dall wrote: I don't view it as 'the kernel requires this' but as 'the kernel will not complain with arbitrary error code if you set the devid flag' capability, and it's up to

Re: [PATCH 2/7] KVM: kvm_host: add kvm_extended_msi

Hi Eric, just played a bit with the code and I could make things easier by the following change: On 29/06/15 16:37, Eric Auger wrote: Add a new kvm_extended_msi struct to store the additional device ID specific to ARM. kvm_kernel_irq_routing_entry union now encompasses this new struct.

Re: [PATCH 7/7] KVM: arm: implement kvm_set_msi by gsi direct mapping

Hi Eric, On 29/06/15 16:37, Eric Auger wrote: If the ITS modality is not available, let's simply support MSI injection by transforming the MSI.data into an SPI ID. This becomes possible to use KVM_SIGNAL_MSI ioctl for arm too. Signed-off-by: Eric Auger eric.au...@linaro.org ---

Re: [PATCH 1/7] KVM: api: add kvm_irq_routing_extended_msi

Hi Pavel, On 02/07/15 08:26, Pavel Fedin wrote: Hello! -Original Message- From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On Behalf Of Eric Auger Sent: Monday, June 29, 2015 6:37 PM To: eric.au...@st.com; eric.au...@linaro.org;

Re: [PATCH 4/7] KVM: arm/arm64: enable irqchip routing

Hi Eric, On 29/06/15 16:37, Eric Auger wrote: This patch adds compilation and link against irqchip. On ARM, irqchip routing is not really useful since there is a single irqchip. However main motivation behind using irqchip code is to enable MSI routing code. With the support of in-kernel

Re: [PATCH 1/7] KVM: api: add kvm_irq_routing_extended_msi

Hi Pavel, On 06/07/15 14:32, Pavel Fedin wrote: Hi! Well, as we are about to implement this: yes. But the issue is that MSI injection and GSI routing code is generic PCI code in userland (at least in kvmtool, guess in QEMU, too), so I don't want to pull in any kind of ARM specific code in

Re: [PATCH 1/7] KVM: api: add kvm_irq_routing_extended_msi

Salut Eric, ITS code in qemu just does: ---cut --- msi_supported = true; kvm_msi_flags = KVM_MSI_VALID_DEVID; kvm_msi_via_irqfd_allowed = kvm_has_gsi_routing(); kvm_gsi_routing_allowed = kvm_msi_via_irqfd_allowed; --- cut --- I set KVM_MSI_VALID_DEVID

Re: [PATCH 1/7] KVM: api: add kvm_irq_routing_extended_msi

On 06/07/15 13:08, Christoffer Dall wrote: On Mon, Jul 06, 2015 at 12:23:19PM +0100, Andre Przywara wrote: Hi Paolo, thanks for looking at this! On 06/07/15 12:07, Paolo Bonzini wrote: On 06/07/2015 12:37, Christoffer Dall wrote: I don't view it as 'the kernel requires

Re: [PATCH 1/7] KVM: api: add kvm_irq_routing_extended_msi

On 06/07/15 16:54, Paolo Bonzini wrote: On 06/07/2015 17:37, Andre Przywara wrote: Wouldn't: if (kvm_vm_check_extension(s, KVM_CAP_MSI_DEVID)) { kroute.flags = KVM_MSI_VALID_DEVID; kroute.u.msi.devid = (pci_bus_num(dev-bus) 8) | dev-devfn; } be saner (without

Re: [PATCH v2] EDAC: Add ARM64 EDAC

On 23/10/15 02:41, Hanjun Guo wrote: > Hi Brijesh, > > On 2015/10/22 22:46, Brijesh Singh wrote: >> Hi Andre, >> >> On 10/21/2015 06:52 PM, Andre Przywara wrote: >>> On 21/10/15 21:41, Brijesh Singh wrote: >>>> Add support for Cortex A57 and

Re: [PATCH v2] EDAC: Add ARM64 EDAC

On 21/10/15 21:41, Brijesh Singh wrote: > Add support for Cortex A57 and A53 EDAC driver. Hi Brijesh, thanks for the quick update! Some comments below. > > Signed-off-by: Brijesh Singh > CC: robh...@kernel.org > CC: pawel.m...@arm.com > CC: mark.rutl...@arm.com >

Re: [PATCH] serial: atmel: fix compiler warning on address cast

Hi, On 08/10/15 11:38, Alexandre Belloni wrote: > On 08/10/2015 at 10:37:49 +0100, Russell King - ARM Linux wrote : >> On Thu, Oct 08, 2015 at 11:01:48AM +0200, Alexandre Belloni wrote: >>> On 05/10/2015 at 18:00:52 +0100, Andre Przywara wrote : >>>> Turning

Re: [PATCH] EDAC: Add AMD Seattle SoC EDAC

Hi, On 21/10/15 10:35, Borislav Petkov wrote: > On Wed, Oct 21, 2015 at 09:55:43AM +0800, Hanjun Guo wrote: >> So I think the meaning of those error register is the same, but the way >> of handle it may different from SoCs, for single bit error: >> >> - SoC may trigger a interrupt; >> - SoC may

[PATCH 4/4] arm64: dts: add .dts for GICv3 Foundation model

Foundation model to run with a GICv3. Signed-off-by: Andre Przywara <andre.przyw...@arm.com> --- arch/arm64/boot/dts/arm/Makefile| 2 +- arch/arm64/boot/dts/arm/foundation-v8-gicv3.dts | 30 + 2 files changed, 31 insertions(+), 1 deletion(-) creat

[PATCH 0/4] add support for GICv3 on the Foundation model

/foundation-model.php Andre Przywara (4): arm64: dts: prepare foundation-v8.dts to cope with GICv3 arm64: dts: Foundation model: increate GICC region to allow EOImode=1 arm64: dts: split Foundation model dts to put the GIC separately arm64: dts: add .dts for GICv3 Foundation model arch/arm64

[PATCH 2/4] arm64: dts: Foundation model: increate GICC region to allow EOImode=1

Recent commits made the GIC driver use EOImode=1 for all GICs that advertise the proper GICC region size. To let the model benefit from the blessings of that mode, increase the GICC region to its actual size of 8K. Signed-off-by: Andre Przywara <andre.przyw...@arm.com> --- arch/arm64/bo

[PATCH 3/4] arm64: dts: split Foundation model dts to put the GIC separately

.dts. Signed-off-by: Andre Przywara <andre.przyw...@arm.com> --- arch/arm64/boot/dts/arm/foundation-v8.dts | 223 + .../arm/{foundation-v8.dts => foundation-v8.dtsi} | 12 -- 2 files changed, 2 insertions(+), 233 deletions(-) copy arch/arm64/boot/dts/arm/{f

[PATCH 1/4] arm64: dts: prepare foundation-v8.dts to cope with GICv3

To prepare the ARM foundation model to support GICv3, we adjust the #address-cells property of the current GICv2 node to be compatible with the two cells required for GICv3 later. Signed-off-by: Andre Przywara <andre.przyw...@arm.com> --- arch/arm64/boot/dts/arm/foundation-v8.dt

Re: [PATCH 4/4] arm64: dts: add .dts for GICv3 Foundation model

Hi Marc, On 13/10/15 11:44, Marc Zyngier wrote: > On 13/10/15 10:37, Andre Przywara wrote: >> The ARMv8 Foundation model sports a command line parameter to use >> a GICv3 emulation instead of the default GICv2 interrupt controller. >> Add a new .dts file which reuses mo

Re: [PATCH 1/7] KVM: api: add kvm_irq_routing_extended_msi

Good morning Pavel, On 07/07/15 08:16, Pavel Fedin wrote: Hello! Wouldn't: if (kvm_vm_check_extension(s, KVM_CAP_MSI_DEVID)) { kroute.flags = KVM_MSI_VALID_DEVID; kroute.u.msi.devid = (pci_bus_num(dev-bus) 8) | dev-devfn; } be saner (without a global variable)?

[PATCH] arm: dma-mapping: fix build warning with new DMA_ERROR_CODE definition

uot; in __iommu_create_mapping() and move the variable declaration inside the for-loop to make the scope of this variable more clear. Signed-off-by: Andre Przywara <andre.przyw...@arm.com> --- arch/arm/mm/dma-mapping.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) Hi Russell,

[PATCH] iommu-common: only compile lib/iommu_common.c for Sparc64

isn't trivial. So for the time being restrict this code to be compiled only when we actually need it. Compile tested on Sparc, Sparc64, PPC64, ARM, ARM64, x86. Signed-off-by: Andre Przywara <andre.przyw...@arm.com> --- arch/sparc/Kconfig | 3 +++ lib/Makefile | 3 ++- 2 files chan

[PATCH] iommu-common: fix return type of iommu_tbl_range_alloc()

any warnings on the architectures I managed to compile. Compile tested on Sparc, Sparc64, PowerPC64, ARM, ARM64, x86. Signed-off-by: Andre Przywara <andre.przyw...@arm.com> --- include/linux/iommu-common.h | 12 ++-- lib/iommu-common.c | 15 --- 2 files chang

Re: [PATCH 2/2] selftests/userfaultfd: improve syscall number definition

Hi Michael, On 23/09/15 10:55, Michael Ellerman wrote: > On Tue, 2015-09-22 at 18:15 +0100, Andre Przywara wrote: >> On 22/09/15 15:06, Andrea Arcangeli wrote: >>> Andre, could you see if linux-next (which includes -mm) works for you >>> by just running "cd too

Re: [PATCH] generic syscalls: wire up userfaultfd syscall

On 22/09/15 16:52, Will Deacon wrote: > On Tue, Sep 22, 2015 at 11:52:19AM +0100, Andre Przywara wrote: >> Enable the new userfaultfd syscall in the generic syscall table. >> Briefly tested on arm64 with the selftest from the tools directory. > > Can you update the selftest t

Re: [PATCH 2/2] selftests/userfaultfd: improve syscall number definition

Hi Shuah, Andrea, On 22/09/15 15:06, Andrea Arcangeli wrote: > On Tue, Sep 22, 2015 at 07:49:13AM -0600, Shuah Khan wrote: >> On 09/22/2015 04:45 AM, Andre Przywara wrote: >>> At the moment the userfaultfd test program only supports x86 and an >>> architecture ca

[PATCH 1/2] userfaultfd: remove kernel header include from uapi header

needed there, so we can simply remove it to fix that issue. Signed-off-by: Andre Przywara <andre.przyw...@arm.com> --- include/uapi/linux/userfaultfd.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/include/uapi/linux/userfaultfd.h b/include/uapi/linux/userfaultfd.h index df0e09b..9

[PATCH 0/2] selftests/userfaultfd: fix build

-proof. Tested on x86, arm and arm64. Andre Przywara (2): userfaultfd: remove kernel header include from uapi header selftests/userfaultfd: improve syscall number definition include/uapi/linux/userfaultfd.h | 2 -- tools/testing/selftests/vm/userfaultfd.c | 13 - 2 files

[PATCH 2/2] selftests/userfaultfd: improve syscall number definition

and guard the explicit syscall number section below to avoid redefinitions. Signed-off-by: Andre Przywara <andre.przyw...@arm.com> --- tools/testing/selftests/vm/userfaultfd.c | 13 - 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/tools/testing/selftests/vm/userfa

Re: [PATCH] arm: wire up userfaultfd and membarrier syscalls

Hi Russell, On 21/09/15 18:17, Russell King - ARM Linux wrote: > On Mon, Sep 21, 2015 at 06:00:33PM +0100, Andre Przywara wrote: >> Add the syscall numbers to the ARM syscall table. Both have >> been briefly tested using the provided selftests from the tools >> direct

[PATCH] generic syscalls: wire up userfaultfd syscall

Enable the new userfaultfd syscall in the generic syscall table. Briefly tested on arm64 with the selftest from the tools directory. Signed-off-by: Andre Przywara <andre.przyw...@arm.com> --- include/uapi/asm-generic/unistd.h | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff

Re: [PATCH] iommu-common: only compile lib/iommu_common.c for Sparc64

Hi David, On 17/09/15 19:38, David Miller wrote: > From: Andre Przywara <andre.przyw...@arm.com> > Date: Thu, 17 Sep 2015 09:40:27 +0100 > >> It seems the types used in this file are not really correct, but a >> fix isn't trivial. So for the time being restrict this

[PATCH] arm: wire up userfaultfd and membarrier syscalls

Add the syscall numbers to the ARM syscall table. Both have been briefly tested using the provided selftests from the tools directory. Signed-off-by: Andre Przywara <andre.przyw...@arm.com> --- Hi Russell, I saw that Thierry sent something similar beginning of August already (which

[PATCH] sparc(64)/iommu: fixup iommu_tbl_range_alloc() types

the obvious mismatches to allow sane comparisons with the error return value. Compile-tested on sparc, sparc64, x86, ARM, arm64. Signed-off-by: Andre Przywara <andre.przyw...@arm.com> --- Hi David, as promised my first naive try on fixing the callers of iommu_tbl_range_alloc() as well. This goes

  1   2   3   4   5   6   7   8   9   10   >