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
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
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
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
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
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 Er
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;
>>
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
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;
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
> ---
> arch/arm/kvm/Kconfig
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.
>
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:
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;
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.
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
---
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
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
)))__cmpxchg_mb((ptr), \
^
kernel/acct.c:174:2: note: in expansion of macro 'cmpxchg'
cmpxchg(>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
)))__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
) {
^
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
---
fs/nfs/nfs4proc.c | 11
) {
^
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
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
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
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 s
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 +,
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
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
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
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
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
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
tic inline function to
get rid of this warning.
Signed-off-by: Andre Przywara
---
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 contains
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
tic inline function to
get rid of this warning.
Signed-off-by: Andre Przywara
---
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..0e51
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
the patching in the module's code.
Signed-off-by: Andre Przywara
---
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 for this, I
guess). I have
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
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
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.
cted CPU is detected at runtime.
Signed-off-by: Andre Przywara
---
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_errat
accessors).
Signed-off-by: Andre Przywara
---
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/cpufeature.h
index cd4ac05
t affected. By default
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
---
arch/arm64/Kconfig
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
-by: Andre Przywara
---
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(+), 1 deletion(-)
create
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
---
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
---
arch/arm64/include/asm/cpufeature.h |5 +++--
arch/arm64
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
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
-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
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
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
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
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
On 13/11/14 15:02, Nikolay Nikolaev wrote:
> On Thu, Nov 13, 2014 at 4:23 PM, Eric Auger 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
wrote:
> On Mon, Nov 10, 2014 at
Hi Nikolay,
On 13/11/14 12:29, Nikolay Nikolaev wrote:
> On Thu, Nov 13, 2014 at 1:52 PM, Andre Przywara
> wrote:
>> Hi Nikolay,
>>
>> On 13/11/14 11:37, Marc Zyngier wrote:
>>> [fixing Andre's email address]
>>>
>>> On 13/11/14 11:20, Christo
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
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:
-
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
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:
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
>> wrote:
>>> I see a crash with 3.18-rc1 on a Juno board related to bpf_jit (see dump
>>> below). User
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
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
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
Hi Rob,
On 02/09/14 18:38, Rob Herring wrote:
> On Tue, Sep 2, 2014 at 8:48 AM, Arnd Bergmann 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
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 wrote:
>>> On Tuesday 02 September 2014 08:20:53 Rob Herring wrote:
>>
>> This alone is not okay. There is no such implementation of
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 Architect
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
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.
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
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
> wrote:
>> The ARM Server Base System Architecture (SBSA) describes a generic
>> UART which all compliant level 1 systems should implement. This is
&
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
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?
>
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?
Commit-ID: 2bbf0a1427c377350f001fbc6260995334739ad7
Gitweb: http://git.kernel.org/tip/2bbf0a1427c377350f001fbc6260995334739ad7
Author: Andre Przywara
AuthorDate: Wed, 31 Oct 2012 17:20:50 +0100
Committer: H. Peter Anvin
CommitDate: Wed, 31 Oct 2012 13:06:55 -0700
x86, amd: Disable way
Commit-ID: 2bbf0a1427c377350f001fbc6260995334739ad7
Gitweb: http://git.kernel.org/tip/2bbf0a1427c377350f001fbc6260995334739ad7
Author: Andre Przywara andre.przyw...@amd.com
AuthorDate: Wed, 31 Oct 2012 17:20:50 +0100
Committer: H. Peter Anvin h...@linux.intel.com
CommitDate: Wed, 31 Oct
From: Andre Przywara
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/hypermail/linux/kernel/1107.3
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
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
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
On 10/24/2012 12:46 PM, Ingo Molnar wrote:
* Andre Przywara 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
---
arch/x86/kernel/cpu/amd.c | 14 ++
1 file
Commit-ID: bffd5fc26043cce33158d4e027576e79fab2f7bb
Gitweb: http://git.kernel.org/tip/bffd5fc26043cce33158d4e027576e79fab2f7bb
Author: Andre Przywara
AuthorDate: Tue, 9 Oct 2012 17:38:35 +0200
Committer: Ingo Molnar
CommitDate: Wed, 24 Oct 2012 08:53:13 +0200
x86/perf: Fix
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
---
arch/x86/kernel/cpu/amd.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86
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
Commit-ID: bffd5fc26043cce33158d4e027576e79fab2f7bb
Gitweb: http://git.kernel.org/tip/bffd5fc26043cce33158d4e027576e79fab2f7bb
Author: Andre Przywara andre.przyw...@amd.com
AuthorDate: Tue, 9 Oct 2012 17:38:35 +0200
Committer: Ingo Molnar mi...@kernel.org
CommitDate: Wed, 24 Oct 2012 08
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
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
trace a7919e7f17c0a725 ]---
The new code will change every of the 16 low bits read from the
register and tries to write and read-back that modified number
from the MSR.
Signed-off-by: Andre Przywara
---
arch/x86/kernel/cpu/perf_event.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions
trace a7919e7f17c0a725 ]---
The new code will change every of the 16 low bits read from the
register and tries to write and read-back that modified number
from the MSR.
Signed-off-by: Andre Przywara
---
arch/x86/kernel/cpu/perf_event.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions
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
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
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
On 09/15/2012 01:20 PM, Konrad Rzeszutek Wilk wrote:
On Sep 4, 2012 4:26 AM, "Andre Przywara" 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, mea
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
driver does not help.
Are there still any 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 &qu
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
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
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
not succeed.
Signed-off-by: Andre Przywara
---
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
--- a/drivers/cpufreq/powernow-k8
control to acpi-cpufreq.
Signed-off-by: Matthew Garrett
Signed-off-by: Andre Przywara
---
arch/x86/include/asm/msr-index.h | 2 ++
drivers/cpufreq/Kconfig.x86 | 3 ++-
drivers/cpufreq/acpi-cpufreq.c | 43 ++--
3 files changed, 41 insertions(+), 7 deletions
the usage.
A following 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
---
Documentation/ABI/testing/sysfs-devices-system-cpu | 11 ++
Documentatio
801 - 900 of 945 matches
Mail list logo
