On Mon, Mar 20, 2017 at 05:49:03PM +1100, Benjamin Herrenschmidt wrote: > Otherwise KVM guests might mess with it even when told not > to causing bad thing interrupts in the host > > Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org>
I've tested this on a P8, with a kernel and QEMU close to their respective current master branches, and if: * the host is configured without CONFIG_PPC_TRANSACTIONAL_MEM, * and the guest is configured with CONFIG_PPC_TRANSACTIONAL_MEM, * and the guest runs a program that uses HTM (in my tests, just a loop doing some floating point multiplies in a transaction)... Without the patch the host will OOPS, usually in __kvmppc_vcore_entry, and kill QEMU. On a busy host this is sometimes followed by "Oops: Bad kernel stack pointer, sig: 6" and the host dies. With the patch the userspace test program is killed with a SIGILL. The guest and host are unaffected. Cheers, Sam. > --- > arch/powerpc/kernel/setup_64.c | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c > index 9cfaa8b..b372b23 100644 > --- a/arch/powerpc/kernel/setup_64.c > +++ b/arch/powerpc/kernel/setup_64.c > @@ -236,6 +236,16 @@ static void cpu_ready_for_interrupts(void) > mtspr(SPRN_LPCR, lpcr | LPCR_AIL_3); > } > > + /* > + * Fixup HFSCR:TM based on CPU features. The bit is set by our > + * early asm init because at that point we haven't updated our > + * CPU features from firmware and device-tree. Here we have, > + * so let's do it > + */ > + if (early_cpu_has_feature(CPU_FTR_HVMODE) && > + !early_cpu_has_feature(CPU_FTR_TM_COMP)) > + mtspr(SPRN_HFSCR, mfspr(SPRN_HFSCR) & ~HFSCR_TM); > + > /* Set IR and DR in PACA MSR */ > get_paca()->kernel_msr = MSR_KERNEL; > } > -- > 2.9.3
