linux-kernel - Re: [PATCH RFC] KVM: Use maple tree to manage memory attributes.

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: <ZsdsqHOtsMDSWMuC@google.com>
Date: Thu, 22 Aug 2024 09:51:52 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Peng Zhang <zhangpeng.00@...edance.com>
Cc: pbonzini@...hat.com, chao.p.peng@...ux.intel.com, Liam.Howlett@...cle.com, 
	kvm@...r.kernel.org, linux-kernel@...r.kernel.org, 
	maple-tree@...ts.infradead.org
Subject: Re: [PATCH RFC] KVM: Use maple tree to manage memory attributes.

On Thu, Aug 22, 2024, Peng Zhang wrote:
> Currently, xarray is used to manage memory attributes. The memory
> attributes management here is an interval problem. However, xarray is
> not suitable for handling interval problems. It may cause memory waste
> and is not efficient. Switching it to maple tree is more elegant. Using
> maple tree here has the following three advantages:
> 1. Less memory overhead.
> 2. More efficient interval operations.
> 3. Simpler code.
> 
> This is the first user of the maple tree interface mas_find_range(),
> and it does not have any test cases yet, so its stability is unclear.
> 
> Signed-off-by: Peng Zhang <zhangpeng.00@...edance.com>
> ---
>  include/linux/kvm_host.h |  5 +++--
>  virt/kvm/kvm_main.c      | 47 ++++++++++++++--------------------------
>  2 files changed, 19 insertions(+), 33 deletions(-)
> 
> I haven't tested this code yet, and I'm not very familiar with kvm, so I'd
> be happy if someone could help test it. This is just an RFC now. Any comments
> are welcome.

Unfortunatley, you are unlikely to get much feedback (although Matthew already
jumped in).  We (KVM folks) know the xarray usage for memory attribute is
(very) suboptimal, and it's on the todo list to address.  We specifically went
with a simple-but-slow implementation in order to prioritize correctness above
all else for initial merge.