> > > > Please consider s390 and (x86/arm) KVM. Once we have a few, more can
> > > > follow later, but I think its important to not only have PPC support for
> > > > this.
> > >
> > > Actually the s390 preemted check via sigp sense running is available for
> > > all hypervisors (z/VM, LPAR and KVM
hi, Paolo
thanks for your reply.
在 2016/9/30 14:58, Paolo Bonzini 写道:
Please consider s390 and (x86/arm) KVM. Once we have a few, more can
follow later, but I think its important to not only have PPC support for
this.
Actually the s390 preemted check via sigp sense running is availab
On 30/09/2016 10:52, Pan Xinhui wrote:
>> x86 has no hypervisor support, and I'd like to understand the desired
>> semantics first, so I don't think it should block this series. In
>
> Once a guest do a hypercall or something similar, IOW, there is a
> kvm_guest_exit. we think this is a lock ho
On Thu, Sep 29, 2016 at 07:19:48PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Tue, Sep 27, 2016 at 04:18:46PM +0200, Jiri Olsa escreveu:
> > On Mon, Sep 26, 2016 at 09:59:54AM -0700, Andi Kleen wrote:
> > > On Mon, Sep 26, 2016 at 12:03:43PM -0300, Arnaldo Carvalho de Melo wrote:
> > > > Em Mon, S
在 2016/9/30 17:08, Paolo Bonzini 写道:
On 30/09/2016 10:52, Pan Xinhui wrote:
x86 has no hypervisor support, and I'd like to understand the desired
semantics first, so I don't think it should block this series. In
Once a guest do a hypercall or something similar, IOW, there is a
kvm_guest_e
On 30/09/16 10:51, Michael Ellerman wrote:
> The fadump code calls vmcore_cleanup() which only exists if
> CONFIG_PROC_VMCORE=y. We don't want to depend on CONFIG_PROC_VMCORE,
> because it's user selectable, so just wrap the call in an #ifdef.
>
> Signed-off-by: Michael Ellerman
> ---
> arch/p
From: Anton Blanchard
We see big improvements with the VMX crypto functions (often 10x or more),
so enable it as a module.
Signed-off-by: Anton Blanchard
---
arch/powerpc/configs/powernv_defconfig | 2 ++
arch/powerpc/configs/ppc64_defconfig | 2 ++
arch/powerpc/configs/pseries_defconfig | 2
From: Anton Blanchard
When we issue a system reset, every CPU in the box prints an Oops,
including a backtrace. Each of these can be quite large (over 4kB)
and we may end up wrapping the ring buffer and losing important
information.
Bump the base size from 128kB to 256kB and the per CPU size fro
From: Anton Blanchard
Change a few devices and filesystems that are seldom used any more
from built in to modules. This reduces our vmlinux about 500kB.
Signed-off-by: Anton Blanchard
---
arch/powerpc/configs/powernv_defconfig | 14 +++---
arch/powerpc/configs/ppc64_defconfig | 14 ++
From: Anton Blanchard
We are starting to see i40e adapters in recent machines, so enable
it in our configs.
Signed-off-by: Anton Blanchard
---
arch/powerpc/configs/powernv_defconfig | 1 +
arch/powerpc/configs/ppc64_defconfig | 1 +
arch/powerpc/configs/pseries_defconfig | 1 +
3 files chang
On 09/30/2016 08:58 AM, Paolo Bonzini wrote:
> Please consider s390 and (x86/arm) KVM. Once we have a few, more can
> follow later, but I think its important to not only have PPC support for
> this.
Actually the s390 preemted check via sigp sense running is available for
Add HAVE_CC_STACKPROTECTOR to powerpc. This is copied from ARM.
Not tested on PPC64, compile ok with ppc64_defconfig
Christophe Leroy (2):
powerpc: initial stack protector (-fstack-protector) support
powerpc/32: stack protector: change the canary value per task
arch/powerpc/Kconfig
Partialy copied from commit c743f38013aef ("ARM: initial stack protector
(-fstack-protector) support")
This is the very basic stuff without the changing canary upon
task switch yet. Just the Kconfig option and a constant canary
value initialized at boot time.
Cc: Nicolas Pitre
Signed-off-by: Ch
Partially copied from commit df0698be14c66 ("ARM: stack protector:
change the canary value per task")
A new random value for the canary is stored in the task struct whenever
a new task is forked. This is meant to allow for different canary values
per task. On powerpc, GCC expects the canary valu
Le 30/09/2016 à 18:26, Denis Kirjanov a écrit :
On Friday, September 30, 2016, Christophe Leroy mailto:christophe.le...@c-s.fr>> wrote:
Add HAVE_CC_STACKPROTECTOR to powerpc. This is copied from ARM.
Not tested on PPC64, compile ok with ppc64_
Hi Christophe,
are you going to test
On Wed, Sep 28, 2016 at 04:15:11PM +0530, Arvind Yadav wrote:
> Free memory mapping, if probe is not successful.
Please use proper subsystem tags for patches. Hint: use git log to find that
out
Applied after fixing the tag
--
~Vinod
On Fri, 2016-09-30 at 18:38 +0200, Christophe LEROY wrote:
> I don't have any ppc64 target, I only have mpc8xx and mpc83xx which
> both
> are ppc32
That's what qemu is for :-)
Cheers,
Ben.
On Friday, September 30, 2016, Christophe Leroy
wrote:
> Add HAVE_CC_STACKPROTECTOR to powerpc. This is copied from ARM.
>
> Not tested on PPC64, compile ok with ppc64_
Hi Christophe,
are you going to test it on ppc64? If not, I can take it
>
> Christophe Leroy (2):
> powerpc: initial stac
18 matches
Mail list logo
