On Fri, 2021-12-17 at 14:55 -0600, Tom Lendacky wrote:
> On 12/17/21 2:13 PM, David Woodhouse wrote:
> > On Fri, 2021-12-17 at 13:46 -0600, Tom Lendacky wrote:
> > > There's no WARN or PANIC, just a reset. I can look to try and capture some
> > > KVM trace data if that would help. If so, let me know what events you'd
> > > like captured.
> > 
> > 
> > Could start with just kvm_run_exit?
> > 
> > Reason 8 would be KVM_EXIT_SHUTDOWN and would potentially indicate a
> > triple fault.
> 
> qemu-system-x86-24093   [005] .....  1601.759486: kvm_exit: vcpu 112 reason shutdown rip 0xffffffff81070574 info1 0x0000000000000000 info2 0x0000000000000000 intr_info 0x80000b08 error_code 0x00000000
> 
> # addr2line -e woodhouse-build-x86_64/vmlinux 0xffffffff81070574
> /root/kernels/woodhouse-build-x86_64/./arch/x86/include/asm/desc.h:272
> 
> Which is: asm volatile("ltr %w0"::"q" (GDT_ENTRY_TSS*8));

OK, that seems like enough of a smoking gun; I'll stare at that harder. Thanks.

/*
 * The LTR instruction marks the TSS GDT entry as busy. On 64-bit, the GDT is
 * a read-only remapping. To prevent a page fault, the GDT is switched to the
 * original writeable version when needed.
 */
#ifdef CONFIG_X86_64
static inline void native_load_tr_desc(void)
{
        struct desc_ptr gdt;
        int cpu = raw_smp_processor_id();
        bool restore = 0;
        struct desc_struct *fixmap_gdt;

        native_store_gdt(&gdt);
        fixmap_gdt = get_cpu_gdt_ro(cpu);

        /*
         * If the current GDT is the read-only fixmap, swap to the original
         * writeable version. Swap back at the end.
         */
        if (gdt.address == (unsigned long)fixmap_gdt) {
                load_direct_gdt(cpu);
                restore = 1;
        }
        asm volatile("ltr %w0"::"q" (GDT_ENTRY_TSS*8));
        if (restore)
                load_fixmap_gdt(cpu);
}