linux-kernel - Re: [PATCH] KVM: x86/mmu: Do not create SPTEs for GFNs that exceed host.MAXPHYADDR

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 2 May 2022 16:51:54 +0000
From:   Sean Christopherson <seanjc@...gle.com>
To:     Maxim Levitsky <mlevitsk@...hat.com>
Cc:     Paolo Bonzini <pbonzini@...hat.com>,
        Vitaly Kuznetsov <vkuznets@...hat.com>,
        Wanpeng Li <wanpengli@...cent.com>,
        Jim Mattson <jmattson@...gle.com>,
        Joerg Roedel <joro@...tes.org>, kvm@...r.kernel.org,
        linux-kernel@...r.kernel.org, Ben Gardon <bgardon@...gle.com>,
        David Matlack <dmatlack@...gle.com>
Subject: Re: [PATCH] KVM: x86/mmu: Do not create SPTEs for GFNs that exceed
 host.MAXPHYADDR

On Mon, May 02, 2022, Maxim Levitsky wrote:
> On Mon, 2022-05-02 at 10:59 +0300, Maxim Levitsky wrote:
> > > > Also I can reproduce it all the way to 5.14 kernel (last kernel I have installed in this VM).
> > > > 
> > > > I tested kvm/queue as of today, sadly I still see the warning.
> > > 
> > > Due to a race, the above statements are out of order ;-)
> > 
> > So futher investigation shows that the trigger for this *is* cpu_pm=on :(
> > 
> > So this is enough to trigger the warning when run in the guest:
> > 
> > qemu-system-x86_64  -nodefaults  -vnc none -serial stdio -machine accel=kvm
> > -kernel x86/dummy.flat -machine kernel-irqchip=on -smp 8 -m 1g -cpu host
> > -overcommit cpu-pm=on
> > 
> > 
> > '-smp 8' is needed, and the more vCPUs the more often the warning appears.
> > 
> > 
> > Due to non atomic memslot update bug, I use patched qemu version, with an
> > attached hack, to pause/resume vcpus around the memslot update it does, but
> > even without this hack, you can just ctrl+c the test after it gets the KVM
> > internal error, and then tdp mmu memory leak warning shows up (not always
> > but very often).
> > 
> > 
> > Oh, and if I run the above command on the bare metal, it  never terminates.
> > Must be due to preemption, qemu shows beeing stuck in kvm_vcpu_block. AVIC
> > disabled, kvm/queue.  Bugs, bugs, and features :)
> 
> All right, at least that was because I removed the '-device isa-debug-exit,iobase=0xf4,iosize=0x4',
> which is apparently used by KVM unit tests to signal exit from the VM.

Can you provide your QEMU command line for running your L1 VM?  And your L0 and L1
Kconfigs too?  I've tried both the dummy and ipi_stress tests on a variety of hardware,
kernels, QEMUs, etc..., with no luck.