[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1c524181-5518-44bb-9985-d9d12bb92073@redhat.com>
Date: Fri, 15 Nov 2024 11:31:19 +0100
From: David Hildenbrand <david@...hat.com>
To: Elliot Berman <quic_eberman@...cinc.com>,
Paolo Bonzini <pbonzini@...hat.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Sean Christopherson <seanjc@...gle.com>, Fuad Tabba <tabba@...gle.com>,
Ackerley Tng <ackerleytng@...gle.com>, Mike Rapoport <rppt@...nel.org>,
"H. Peter Anvin" <hpa@...or.com>
Cc: James Gowans <jgowans@...zon.com>, linux-fsdevel@...r.kernel.org,
kvm@...r.kernel.org, linux-coco@...ts.linux.dev,
linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-mm@...ck.org
Subject: Re: [PATCH RFC v3 0/2] mm: Refactor KVM guest_memfd to introduce
guestmem library
On 13.11.24 23:34, Elliot Berman wrote:
> In preparation for adding more features to KVM's guest_memfd, refactor
> and introduce a library which abtracts some of the core-mm decisions
> about managing folios associated with guest memory. The goal of the
> refactor serves two purposes:
>
> 1. Provide an easier way to reason about memory in guest_memfd. KVM
> needs to support multiple confidentiality models (TDX, SEV, pKVM, Arm
> CCA). These models support different semantics for when the host
> can(not) access guest memory. An abstraction for the allocator and
> managing the state of pages will make it eaiser to reason about the
> state of folios within the guest_memfd.
>
> 2. Provide a common implementation for other users such as Gunyah [1] and
> guestmemfs [2].
>
> In this initial series, I'm seeking comments for the line I'm drawing
> between library and user (KVM). I've not introduced new functionality in
> this series; the first new feature will probably be Fuad's mappability
> patches [3].
Right, or the dummy mmap + vma->set_policy patches for NUMA handling.
--
Cheers,
David / dhildenb
Powered by blists - more mailing lists