linux-kernel - [GIT PULL] KVM: x86: Changes for 6.17

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250725220713.264711-1-seanjc@google.com>
Date: Fri, 25 Jul 2025 15:07:00 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Paolo Bonzini <pbonzini@...hat.com>
Cc: kvm@...r.kernel.org, linux-kernel@...r.kernel.org, 
	Sean Christopherson <seanjc@...gle.com>
Subject: [GIT PULL] KVM: x86: Changes for 6.17

As promised, the storm has arrived :-)

There are a two anomalies this time around, but thankfully only one conflict,
and a trivial one at that (details on that in the MMIO Stale Data pull request).

1. The "no assignment" pull request depends on the IRQs and MMIO Stale Data
   pull requests.  I created the topic branch based on the IRQs branch (minus
   one commit that came in later), and then merged in the MMIO branch to create
   a common base.  All the commits came out as I wanted, but the diff stats
   generated by `git request-pull` are funky, so I doctored them up, a lot.

2. The "SEV cache maintenance" pull request is based on a tag/branch from the
   tip tree.  I don't think you need to do anything special here?  Except
   possibly mention it to Linus if the KVM pull request happens to get sent
   before the associated tip pull request (which seems unlikely given how they
   send a bunch of small pulls).