Re: [PATCH 0/2] Automatically load the vmx_crypto module if supported

On Wed, 2016-07-13 at 15:47 +1000, alast...@au1.ibm.com wrote: > From: Alastair D'Silva > > This series allows the vmx_crypto module to be detected and > automatically > loaded via UDEV if the CPU supports the vector crypto feature. > > Alastair D'Silva (2): >   powerpc: Add

Re: [PATCH 05/15] cxl: Allow a default context to be associated with an external pci_dev

On 11/07/16 21:50, Ian Munsie wrote: From: Ian Munsie The cxl kernel API has a concept of a default context associated with each PCI device under the virtual PHB. The Mellanox CX4 will also use the cxl kernel API, but it does not use a virtual PHB - rather, the AFU appears

[PATCH 0/2] Automatically load the vmx_crypto module if supported

From: Alastair D'Silva This series allows the vmx_crypto module to be detected and automatically loaded via UDEV if the CPU supports the vector crypto feature. Alastair D'Silva (2): powerpc: Add module autoloading based on CPU features crypto: vmx - Convert to CPU

[PATCH 2/2] crypto: vmx - Convert to CPU feature based module autoloading

From: Alastair D'Silva This patch utilises the GENERIC_CPU_AUTOPROBE infrastructure to automatically load the vmx_crypto module if the CPU supports it. Signed-off-by: Alastair D'Silva --- drivers/crypto/vmx/Kconfig | 2 +- drivers/crypto/vmx/vmx.c

[PATCH 2/2] Automatically load the vmx_crypto module if supported.

From: Alastair D'Silva This patch utilises the GENERIC_CPU_AUTOPROBE infrastructure to automatically load the vmx_crypto module if the CPU supports it. Signed-off-by: Alastair D'Silva --- drivers/crypto/vmx/Kconfig | 2 +- drivers/crypto/vmx/vmx.c

[PATCH 1/2] powerpc: Add module autoloading based on CPU features

From: Alastair D'Silva This patch provides the necessary infrastructure to allow drivers to be automatically loaded via UDEV. It implements the minimum required to be able to use module_cpu_feature_match to trigger the GENERIC_CPU_AUTOPROBE mechanisms. The features exposed

[PATCH 1/2] Allow drivers to be autoloaded.

From: Alastair D'Silva This patch provides the necessary infrastructure to allow drivers to be automatically loaded via UDEV. It implements the minimum required to be able to use module_cpu_feature_match to trigger the GENERIC_CPU_AUTOPROBE mechanisms. The features exposed

Re: [RFC 0/3] extend kexec_file_load system call

Russell King - ARM Linux writes: > On Tue, Jul 12, 2016 at 10:58:05PM +0200, Petr Tesarik wrote: >> I'm not an expert on DTB, so I can't provide an example of code >> execution, but you have already mentioned the /chosen/linux,stdout-path >> property. If an attacker

Re: [PATCH 10/15] cxl: Add preliminary workaround for CX4 interrupt limitation

On 11/07/16 21:50, Ian Munsie wrote: From: Ian Munsie The Mellanox CX4 has a hardware limitation where only 4 bits of the AFU interrupt number can be passed to the XSL when sending an interrupt, limiting it to only 15 interrupts per context (AFU interrupt number 0 is

Re: [PATCH 1/2] crypto: vmx - Adding asm subroutines for XTS

Stephen Rothwell writes: > On Mon, 11 Jul 2016 16:07:39 -0300 Paulo Flabiano Smorigo > wrote: >> >> diff --git a/drivers/crypto/vmx/aesp8-ppc.pl >> b/drivers/crypto/vmx/aesp8-ppc.pl >> index 2280539..813ffcc 100644 >> ---

Re: [RFC 0/3] extend kexec_file_load system call

On 07/12/16 at 03:50pm, Mark Rutland wrote: > On Tue, Jul 12, 2016 at 04:24:10PM +0200, Arnd Bergmann wrote: > > On Tuesday, July 12, 2016 10:18:11 AM CEST Vivek Goyal wrote: > > > > > > > > On Open Firmware, the DT is extracted from running firmware and copied > > > > into dynamically allocated

Re: [PATCH v2 0/3] powerpc: tweak the kernel options for CRASH_DUMP and RELOCATABLE

Please ignore this. Forgot the CC list. Thanks, Kevin On Wed, Jul 13, 2016 at 09:12:53AM +0800, Kevin Hao wrote: > v2: > Compare to v1 [1], the main differences are: > - Still automatically select RELOCATABLE when CRASH_DUMP is enabled. > - Add a new patch to kill RELOCATABLE_PPC32. > > v1: >

[PATCH v2 3/3] powerpc32: kill RELOCATABLE_PPC32

It is seldom used in the kernel code and can be easily replaced by either RELOCATABLE or PPC32. So there is no reason to keep a separate kernel option for this. Signed-off-by: Kevin Hao --- arch/powerpc/Kconfig | 4 arch/powerpc/include/asm/page.h | 6

[PATCH v2 2/3] powerpc: merge the RELOCATABLE config entries for ppc32 and ppc64

It makes no sense to keep two separate RELOCATABLE config entries for ppc32 and ppc64 respectively. Merge them into one and move it to a common place. Signed-off-by: Kevin Hao --- arch/powerpc/Kconfig | 65 ++-- 1 file changed,

[PATCH v2 1/3] powerpc32: booke: fix the build error when CRASH_DUMP is enabled

In the current code, the RELOCATABLE will be forcedly enabled when enabling CRASH_DUMP. But for ppc32, the RELOCABLE also depend on ADVANCED_OPTIONS and select NONSTATIC_KERNEL. This will cause the following build error when CRASH_DUMP=y && ADVANCED_OPTIONS=n because the select of NONSTATIC_KERNEL

[PATCH v2 0/3] powerpc: tweak the kernel options for CRASH_DUMP and RELOCATABLE

v2: Compare to v1 [1], the main differences are: - Still automatically select RELOCATABLE when CRASH_DUMP is enabled. - Add a new patch to kill RELOCATABLE_PPC32. v1: The first patch fixes a build error when CRASH_DUMP=y && ADVANCED_OPTIONS=n for ppc32. The second does some cleanup for

[PATCH v2 0/3] powerpc: tweak the kernel options for CRASH_DUMP and RELOCATABLE

v2: Compare to v1 [1], the main differences are: - Still automatically select RELOCATABLE when CRASH_DUMP is enabled. - Add a new patch to kill RELOCATABLE_PPC32. v1: The first patch fixes a build error when CRASH_DUMP=y && ADVANCED_OPTIONS=n for ppc32. The second does some cleanup for

Re: [RFC 0/3] extend kexec_file_load system call

Vivek Goyal writes: > On Tue, Jul 12, 2016 at 10:58:09AM -0300, Thiago Jung Bauermann wrote: >> Hello Eric, >> >> Am Dienstag, 12 Juli 2016, 08:25:48 schrieb Eric W. Biederman: >> > AKASHI Takahiro writes: >> > > Device tree blob must be passed to

Re: [RFC 0/3] extend kexec_file_load system call

Petr Tesarik writes: > On Tue, 12 Jul 2016 13:25:11 -0300 > Thiago Jung Bauermann wrote: > >> Hi Eric, >> >> I'm trying to understand your concerns leading to your nack. I hope you >> don't mind expanding your thoughts on them a bit. >> >> Am

Re: [PATCH -next] cxl: Use for_each_compatible_node() macro

On 12/07/16 21:30, weiyj...@163.com wrote: From: Wei Yongjun Use for_each_compatible_node() macro instead of open coding it. Generated by Coccinelle. Signed-off-by: Wei Yongjun Reviewed-by: Andrew Donnellan

Re: [PATCH] powerpc: fix oops in pcibios_release_device() after pcibios_free_controller()

Ben, On 07/04/2016 11:55 PM, Benjamin Herrenschmidt wrote: Have you considered instead adding a kref to the PHB and only freeing it when all devices have been freed ? Or it's too hard to tract device creation ? Can you clarify which are the devices that should be tracked w/ krefs to the PHB?

Re: [PATCH v5 18/32] signal: Consolidate {TS, TLF}_RESTORE_SIGMASK code

On Tue, Jul 12, 2016 at 4:57 AM, Brian Gerst wrote: > On Mon, Jul 11, 2016 at 4:53 PM, Andy Lutomirski wrote: >> In general, there's no need for the "restore sigmask" flag to live in >> ti->flags. alpha, ia64, microblaze, powerpc, sh, sparc (64-bit only), >>

Re: [RFC 0/3] extend kexec_file_load system call

On Tue, Jul 12, 2016 at 10:58:05PM +0200, Petr Tesarik wrote: > I'm not an expert on DTB, so I can't provide an example of code > execution, but you have already mentioned the /chosen/linux,stdout-path > property. If an attacker redirects the bootloader to an insecure > console, they may get

Re: [RFC 0/3] extend kexec_file_load system call

On Tue, 12 Jul 2016 16:22:07 -0500 ebied...@xmission.com (Eric W. Biederman) wrote: > Petr Tesarik writes: > > > On Tue, 12 Jul 2016 13:25:11 -0300 > > Thiago Jung Bauermann wrote: >[...] > >> I also don't understand what you mean by code

Re: [RFC 0/3] extend kexec_file_load system call

ebied...@xmission.com (Eric W. Biederman) writes: > Petr Tesarik writes: > >> On Tue, 12 Jul 2016 13:25:11 -0300 >> Thiago Jung Bauermann wrote: >> >>> Hi Eric, >>> >>> I'm trying to understand your concerns leading to your nack. I hope you >>>

Re: [RFC 0/3] extend kexec_file_load system call

Petr Tesarik writes: > On Tue, 12 Jul 2016 13:25:11 -0300 > Thiago Jung Bauermann wrote: > >> Hi Eric, >> >> I'm trying to understand your concerns leading to your nack. I hope you >> don't mind expanding your thoughts on them a bit. >> >> Am

Re: [RFC 0/3] extend kexec_file_load system call

On Tue, 12 Jul 2016 13:25:11 -0300 Thiago Jung Bauermann wrote: > Hi Eric, > > I'm trying to understand your concerns leading to your nack. I hope you > don't mind expanding your thoughts on them a bit. > > Am Dienstag, 12 Juli 2016, 08:25:48 schrieb Eric W.

Re: [PATCH] include: mman: Use bool instead of int for the return value of arch_validate_prot

On 7/12/16 12:20, Michael Ellerman wrote: > Chen Gang writes: > >> On 7/11/16 07:47, Dave Hansen wrote: >>> On 07/09/2016 09:29 AM, cheng...@emindsoft.com.cn wrote: -static inline int arch_validate_prot(unsigned long prot) +static inline bool

Re: [PATCH] cxl: remove dead Kconfig options

> On Jul 4, 2016, at 2:12 AM, Andrew Donnellan > wrote: > > Remove the CXL_KERNEL_API and CXL_EEH Kconfig options, as they were only > needed to coordinate the merging of the cxlflash driver. Also remove the > stub implementation of cxl_perst_reloads_same_image()

Re: [PATCH v2 0/4] implement vcpu preempted check

On 07/12/2016 12:16 AM, Juergen Gross wrote: On 11/07/16 17:10, Waiman Long wrote: On 07/06/2016 02:52 AM, Peter Zijlstra wrote: On Tue, Jun 28, 2016 at 10:43:07AM -0400, Pan Xinhui wrote: change fomr v1: a simplier definition of default vcpu_is_preempted skip mahcine type check on

RE: [PATCH 1/2] crypto: vmx - Adding asm subroutines for XTS

From: Paulo Flabiano Smorigo > Sent: 11 July 2016 20:08 > > This patch add XTS subroutines using VMX-crypto driver. > > It gives a boost of 20 times using XTS. > > These code has been adopted from OpenSSL project in collaboration > with the original author (Andy Polyakov ).

Re: [RFC 0/3] extend kexec_file_load system call

Hi Eric, I'm trying to understand your concerns leading to your nack. I hope you don't mind expanding your thoughts on them a bit. Am Dienstag, 12 Juli 2016, 08:25:48 schrieb Eric W. Biederman: > AKASHI Takahiro writes: > > Device tree blob must be passed to a

Re: [RFC 0/3] extend kexec_file_load system call

On Tue, Jul 12, 2016 at 04:24:10PM +0200, Arnd Bergmann wrote: > On Tuesday, July 12, 2016 10:18:11 AM CEST Vivek Goyal wrote: > > > > > > On Open Firmware, the DT is extracted from running firmware and copied > > > into dynamically allocated data structures. After a kexec, the runtime > > >

Re: [RFC 0/3] extend kexec_file_load system call

On Tuesday, July 12, 2016 10:18:11 AM CEST Vivek Goyal wrote: > > > > On Open Firmware, the DT is extracted from running firmware and copied > > into dynamically allocated data structures. After a kexec, the runtime > > interface to the firmware is not available, so the flattened DT format > >

Re: [RFC 0/3] extend kexec_file_load system call

On Tue, Jul 12, 2016 at 04:02:46PM +0200, Arnd Bergmann wrote: > On Tuesday, July 12, 2016 8:25:48 AM CEST Eric W. Biederman wrote: > > AKASHI Takahiro writes: > > > > > Device tree blob must be passed to a second kernel on DTB-capable > > > archs, like powerpc and

Re: [RFC 0/3] extend kexec_file_load system call

On Tue, Jul 12, 2016 at 10:58:09AM -0300, Thiago Jung Bauermann wrote: > Hello Eric, > > Am Dienstag, 12 Juli 2016, 08:25:48 schrieb Eric W. Biederman: > > AKASHI Takahiro writes: > > > Device tree blob must be passed to a second kernel on DTB-capable > > > archs,

Re: [RFC 0/3] extend kexec_file_load system call

AKASHI Takahiro writes: > Device tree blob must be passed to a second kernel on DTB-capable > archs, like powerpc and arm64, but the current kernel interface > lacks this support. > > This patch extends kexec_file_load system call by adding an extra > argument to

Re: [RFC 0/3] extend kexec_file_load system call

On Tuesday, July 12, 2016 8:25:48 AM CEST Eric W. Biederman wrote: > AKASHI Takahiro writes: > > > Device tree blob must be passed to a second kernel on DTB-capable > > archs, like powerpc and arm64, but the current kernel interface > > lacks this support. > > > >

Re: [RFC 0/3] extend kexec_file_load system call

Hello Eric, Am Dienstag, 12 Juli 2016, 08:25:48 schrieb Eric W. Biederman: > AKASHI Takahiro writes: > > Device tree blob must be passed to a second kernel on DTB-capable > > archs, like powerpc and arm64, but the current kernel interface > > lacks this support. > >

Re: [PATCH v5 00/44] dma-mapping: Use unsigned long for dma_attrs

On 07/12/2016 02:16 PM, Daniel Vetter wrote: > On Thu, Jun 30, 2016 at 10:23:39AM +0200, Krzysztof Kozlowski wrote: >> Hi, >> >> >> This is fifth approach for replacing struct dma_attrs with unsigned >> long. >> >> The main patch (1/44) doing the change is split into many subpatches >> for easier

Re: [PATCH v5 00/44] dma-mapping: Use unsigned long for dma_attrs

On Thu, Jun 30, 2016 at 10:23:39AM +0200, Krzysztof Kozlowski wrote: > Hi, > > > This is fifth approach for replacing struct dma_attrs with unsigned > long. > > The main patch (1/44) doing the change is split into many subpatches > for easier review (2-42). They should be squashed together

Re: [PATCH v5 18/32] signal: Consolidate {TS, TLF}_RESTORE_SIGMASK code

On Mon, Jul 11, 2016 at 4:53 PM, Andy Lutomirski wrote: > In general, there's no need for the "restore sigmask" flag to live in > ti->flags. alpha, ia64, microblaze, powerpc, sh, sparc (64-bit only), > tile, and x86 use essentially identical alternative implementations, >

[PATCH -next] cxl: Use for_each_compatible_node() macro

From: Wei Yongjun Use for_each_compatible_node() macro instead of open coding it. Generated by Coccinelle. Signed-off-by: Wei Yongjun --- drivers/misc/cxl/base.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff

Re: [PATCH 08/15] cxl: Add support for using the kernel API with a real PHB

On 11/07/16 21:50, Ian Munsie wrote: From: Ian Munsie This hooks up support for using the kernel API with a real PHB. After the AFU initialisation has completed it calls into the PHB code to pass it the AFU that will be used by other peer physical functions on the adapter.

Re: [PATCH 07/15] powerpc/powernv: Add support for the cxl kernel api on the real phb

(reviewed late in the evening, apologies if I've missed something) On 11/07/16 21:50, Ian Munsie wrote: From: Ian Munsie This adds support for the peer model of the cxl kernel api to the PowerNV PHB, in which physical function 0 represents the cxl function on the card (an

Re: [PATCH 06/15] cxl: Do not create vPHB if there are no AFU configuration records

On 11/07/16 21:50, Ian Munsie wrote: From: Ian Munsie The vPHB model of the cxl kernel API is a hierarchy where the AFU is represented by the vPHB, and it's AFU configuration records are exposed as functions under that vPHB. If there are no AFU configuration records we

Re: [PATCH V2 5/5] powerpc/kvm/stats: Implement existing and add new halt polling vcpu stats

On 12/07/16 02:49, David Matlack wrote: > On Mon, Jul 11, 2016 at 12:08 AM, Suraj Jitindar Singh > wrote: >> vcpu stats are used to collect information about a vcpu which can be viewed >> in the debugfs. For example halt_attempted_poll and halt_successful_poll >> are

Re: [PATCH 01/14] powerpc/powernv: Add XICS emulation APIs

Benjamin Herrenschmidt writes: > OPAL provides an emulated XICS interrupt controller to > use as a fallback on newer processors that don't have a > XICS. It's meant as a way to provide backward compatibility > with future processors. Add the corresponding interfaces. > >

Re: [PATCH V2 3/5] kvm/ppc/book3s_hv: Implement halt polling in the kvm_hv kernel module

On 12/07/16 03:26, David Matlack wrote: > On Mon, Jul 11, 2016 at 10:07 AM, Paolo Bonzini wrote: >> >> On 11/07/2016 18:57, David Matlack wrote: >>> On Mon, Jul 11, 2016 at 12:08 AM, Suraj Jitindar Singh >>> wrote: This patch introduces new

Re: [PATCH V2 4/5] kvm/stats: Add provisioning for 64-bit vcpu statistics

On 12/07/16 05:45, David Matlack wrote: > On Mon, Jul 11, 2016 at 12:31 PM, Paolo Bonzini wrote: >> >> On 11/07/2016 19:30, David Matlack wrote: >>> On Mon, Jul 11, 2016 at 10:05 AM, Paolo Bonzini wrote: On 11/07/2016 18:51, David Matlack