linux-kernel - Re: [PATCH V2 3/10] KVM/MMU: Add last_level in the struct mmu_spte

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]

Message-ID: <d9043bc8-d006-bf64-2047-79a9b6f98183@redhat.com>
Date:   Fri, 15 Feb 2019 16:22:43 +0100
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     Tianyu Lan <lantianyu1986@...il.com>
Cc:     Lan Tianyu <Tianyu.Lan@...rosoft.com>, christoffer.dall@....com,
        marc.zyngier@....com, linux@...linux.org.uk,
        catalin.marinas@....com, will.deacon@....com, jhogan@...nel.org,
        ralf@...ux-mips.org, paul.burton@...s.com, paulus@...abs.org,
        benh@...nel.crashing.org, mpe@...erman.id.au,
        Radim Krcmar <rkrcmar@...hat.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, bp@...en8.de,
        "H. Peter Anvin" <hpa@...or.com>,
        the arch/x86 maintainers <x86@...nel.org>,
        linux-arm-kernel@...ts.infradead.org, kvmarm@...ts.cs.columbia.edu,
        "linux-kernel@...r kernel org" <linux-kernel@...r.kernel.org>,
        linux-mips@...r.kernel.org, kvm-ppc@...r.kernel.org,
        linuxppc-dev@...ts.ozlabs.org, kvm <kvm@...r.kernel.org>,
        michael.h.kelley@...rosoft.com, kys@...rosoft.com,
        Vitaly Kuznetsov <vkuznets@...hat.com>
Subject: Re: [PATCH V2 3/10] KVM/MMU: Add last_level in the struct
 mmu_spte_page

On 15/02/19 16:05, Tianyu Lan wrote:
> Yes, you are right. Thanks to point out and will fix. The last_level
> flag is to avoid adding middle page node(e.g, PGD, PMD)
> into flush list. The address range will be duplicated if adding both
> leaf, node and middle node into flush list.

Hmm, that's not easy to track.  One kvm_mmu_page could include both leaf
and non-leaf page (for example a huge page for 0 to 2 MB and a page
table for 2 MB to 4 MB).

Is this really needed?  First, your benchmarks so far have been done
with sp->last_level always set to true.  Second, you would only
encounter this optimization in kvm_mmu_commit_zap_page when zapping a 1
GB region (which then would be invalidated twice, at both the PMD and
PGD level) or bigger.

Paolo