linux-kernel - Re: [RFC PATCH v2 0/4] mm, memory_hotplug: allocate memmap from hotadded memory

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: <23d64fa1-386d-bdbf-1546-77eb56fcebc6@redhat.com>
Date:   Tue, 29 Jan 2019 11:08:32 +0100
From:   David Hildenbrand <david@...hat.com>
To:     Oscar Salvador <osalvador@...e.de>
Cc:     linux-mm@...ck.org, mhocko@...e.com, dan.j.williams@...el.com,
        Pavel.Tatashin@...rosoft.com, linux-kernel@...r.kernel.org,
        dave.hansen@...el.com, Vitaly Kuznetsov <vkuznets@...hat.com>
Subject: Re: [RFC PATCH v2 0/4] mm, memory_hotplug: allocate memmap from
 hotadded memory

On 29.01.19 09:43, Oscar Salvador wrote:
> On Fri, Jan 25, 2019 at 09:53:35AM +0100, David Hildenbrand wrote:
> Hi David,
> 
>> I only had a quick glimpse. I would prefer if the caller of add_memory()
>> can specify whether it would be ok to allocate vmmap from the range.
>> This e.g. allows ACPI dimm code to allocate from the range, however
>> other machanisms (XEN, hyper-v, virtio-mem) can allow it once they
>> actually support it.
> 
> Well, I think this can be done, and it might make more sense, as we
> would get rid of some other flags to prevent allocating vmemmap
> besides mhp_restrictions.

Maybe we can also start passing a struct to add_memory() to describe
such properties. This would avoid having to change all the layers over
and over again. We would just have to establish some rules to avoid
breaking stuff. E.g. the struct always has to be initialized to 0 so new
features won't break any caller not wanting to make use of that.

E.g. memory block types (or if we come up with something better) would
also have to add new parameters to add_memory() and friends.

> 
>>
>> Also, while s390x standby memory cannot support allocating from the
>> range, virtio-mem could easily support it on s390x.
>>
>> Not sure how such an interface could look like, but I would really like
>> to have control over that on the add_memory() interface, not per arch.
> 
> Let me try it out and will report back.
> 
> Btw, since you are a virt-guy, would it be do feasible for you to test the patchset
> on hyper-v, xen or your virtio-mem driver?

I don't have a XEN or Hyper-V installation myself. cc-ing Vitaly, maybe
he has time end resources to test on Hyper-V.

I'll be reworking my virtio-mem prototype soon and try with this
patchset than! But this could take a little bit longer as I have tons of
other stuff on my plate :) So don't worry about virtio-mem too much for now.

> 
> Thanks David!
> 

-- 

Thanks,

David / dhildenb