linux-kernel - Re: [RFC PATCH 0/4] mm: Add PG

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: <25f0bab2-439e-9f78-8637-d4f7cac714cc@intel.com>
Date:   Mon, 13 Apr 2020 09:43:41 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     Alex Williamson <alex.williamson@...hat.com>
Cc:     Alexander Duyck <alexander.h.duyck@...ux.intel.com>,
        Mel Gorman <mgorman@...hsingularity.net>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org,
        Andrea Arcangeli <aarcange@...hat.com>,
        Dan Williams <dan.j.williams@...el.com>,
        David Hildenbrand <david@...hat.com>,
        Michal Hocko <mhocko@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        "Raj, Ashok" <ashok.raj@...el.com>
Subject: Re: [RFC PATCH 0/4] mm: Add PG_zero support

On 4/13/20 8:47 AM, Alex Williamson wrote:
>> You can delay pinning until the device is actually used.  That should be
>> late enough for the host to figure out whether a paravirtualized IOMMU
>> is in place.
> So the guest enables the bus master bit in the command register and at
> that point we'd stall the VM for an indeterminate length of time while
> we potentially pin all memory, and hope that both the user and the host
> has the resources to account and allocate that memory, otherwise the
> VM suddenly crashes?  All of this potentially taking place in the
> pre-boot environment to support option ROMs as well.  A delay starting
> the VM seems a lot more predictable.  Thanks,

BTW, there are a million ways to speed up VM startup without both
complicating the core VM *and* slowing down everybody that gets a
speedup from cache-hot pages coming out of the allocator.

Use ramfs or hugetlbfs files.  Have a bunch of them sitting around,
preallocated (and zeroed) and dole them out as VMs start up.

Instead of complicating the core VM, do the pre-zeroing in hugetlbfs.
Zeroing at the time the pages get added to the pool wouldn't be the
worst thing and wouldn't touch the core VM.