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
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
