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: <a1ab1066-ed2a-4a67-54e1-15982645cfe8@redhat.com>
Date:   Tue, 13 Nov 2018 19:22:42 +0100
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     Barret Rhoden <brho@...gle.com>
Cc:     Dan Williams <dan.j.williams@...el.com>,
        Dave Jiang <dave.jiang@...el.com>,
        Ross Zwisler <zwisler@...nel.org>,
        Vishal Verma <vishal.l.verma@...el.com>,
        Radim Krčmář <rkrcmar@...hat.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        linux-nvdimm@...ts.01.org, linux-kernel@...r.kernel.org,
        "H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
        kvm@...r.kernel.org, yu.c.zhang@...el.com, yi.z.zhang@...el.com
Subject: Re: [PATCH 2/2] kvm: Use huge pages for DAX-backed files

On 13/11/2018 17:21, Barret Rhoden wrote:
> On 2018-11-12 at 20:31 Paolo Bonzini <pbonzini@...hat.com> wrote:
>> Looks good.  What's the plan for removing PageReserved from DAX pages?
> 
> I hear that's going on in this thread:
> 
> https://lore.kernel.org/lkml/154145268025.30046.11742652345962594283.stgit@ahduyck-desk1.jf.intel.com/
> 
> Though it looks like it's speeding up page initialization, and not
> explicitly making the PageReserved change, yet.
> 
> Alternatively, I could change kvm_is_reserved_pfn() to single out
> zone_device pages if we don't want to wait or if there is a concern
> that it won't happen.
> 
> On a related note, there are two places in KVM where we check
> PageReserved outside of kvm_is_reserved_pfn().
> 
> For reference:
> 
> bool kvm_is_reserved_pfn(kvm_pfn_t pfn)
> {
>         if (pfn_valid(pfn))
>                 return PageReserved(pfn_to_page(pfn));
> 
>         return true;
> }
> 
> One caller of PageReserved():
> 
> void kvm_set_pfn_dirty(kvm_pfn_t pfn)
> {
>         if (!kvm_is_reserved_pfn(pfn)) {
>                 struct page *page = pfn_to_page(pfn);
> 
>                 if (!PageReserved(page))
>                         SetPageDirty(page);
>         }
> }
> 
> In that one, the PageReserved() check looks redundant, since if the
> page was PageReserved, then it would have been kvm_is_reserved.

Make sense, and a patch to fix this is welcome.

> 
> The other is:
> 
> static bool kvm_is_mmio_pfn(kvm_pfn_t pfn)
> {
>         if (pfn_valid(pfn))
>                 return !is_zero_pfn(pfn) && PageReserved(pfn_to_page(pfn)) &&
>                         /*
>                          * Some reserved pages, such as those from NVDIMM
>                          * DAX devices, are not for MMIO, and can be mapped
>                          * with cached memory type for better performance.
>                          * However, the above check misconceives those pages
>                          * as MMIO, and results in KVM mapping them with UC
>                          * memory type, which would hurt the performance.
>                          * Therefore, we check the host memory type in addition
>                          * and only treat UC/UC-/WC pages as MMIO.
>                          */
>                         (!pat_enabled() || pat_pfn_immune_to_uc_mtrr(pfn));
> 
>         return true;
> }
> 
> Where the PAT stuff was motivated by DAX.  The PageReserved check here
> looks like a broken-out version of kvm_is_reserved_pfn(), so that we can
> make some extra checks around it.

Since this one is indeed motivated by DAX, it can be left in for now and
it will DTRT.  But when DAX is not PageReserved anymore, then this
second part of the condition can be reverted.

Paolo

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ