linux-kernel - Re: [GIT PULL] KVM: x86: Misc changes for 6.6

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: <ZPDbdTIUXAnvL7SM@google.com>
Date:   Thu, 31 Aug 2023 11:27:01 -0700
From:   Sean Christopherson <seanjc@...gle.com>
To:     Paolo Bonzini <pbonzini@...hat.com>
Cc:     kvm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] KVM: x86: Misc changes for 6.6

On Thu, Aug 31, 2023, Paolo Bonzini wrote:
> This is definitely stuff that I wish I took a look for earlier (and
> this is also why I prefer small bits over the development period, as
> it keeps me honest),

I'll work on making this happen.  I think the biggest thing on my end is to make
it easier to track/merge arbitrary topic branches, e.g. so that I can put big
series into their own branches with minimal risk of forgetting to merge them into
kvm-x86/next.

> I'll take a look but I've pulled it anyway.

FWIW, I despise the "goverened features" name, though I like the guest_can_use()
name.

> BTW, not using filemap turned out to be much bigger, and to some
> extent uglier, than I expected. I'll send a message to the private mem
> thread, but I think we should not pursue that for now and do it in a
> separate patch series (if at all) so that it's clearer what filemap_*
> code is being replaced by custom code.

Bummer, I was hoping we could avoid having to touch mm/ code.