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: <6r4wdlkfpnmrox2cndrg4t7ixrpqivgsehfdbvirh3skkuikwr@lauuwibj5bd2>
Date: Thu, 20 Nov 2025 23:32:58 +0000
From: Yosry Ahmed <yosry.ahmed@...ux.dev>
To: Sean Christopherson <seanjc@...gle.com>
Cc: Paolo Bonzini <pbonzini@...hat.com>, Jim Mattson <jmattson@...gle.com>, 
	kvm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 00/23] Extend test coverage for nested SVM

On Thu, Nov 20, 2025 at 03:23:23PM -0800, Sean Christopherson wrote:
> On Tue, Oct 21, 2025, Yosry Ahmed wrote:
> > There are multiple selftests exercising nested VMX that are not specific
> > to VMX (at least not anymore). Extend their coverage to nested SVM.
> > 
> > This version is significantly different (and longer) than v1 [1], mainly
> > due to the change of direction to reuse __virt_pg_map() for nested EPT/NPT
> > mappings instead of extending the existing nested EPT infrastructure. It
> > also has a lot more fixups and cleanups.
> > 
> > This series depends on two other series:
> > - "KVM: SVM: GIF and EFER.SVME are independent" [2]
> > - "KVM: selftests: Add test of SET_NESTED_STATE with 48-bit L2 on 57-bit L1" [3]
> 
> No, it depends on local commits that are very similar to [3], but not precisely
> [3].

Hmm I just applied that series with b4 without local changes, on top of
kvm-x86/next at that time, which was kvm-x86-next-2025.09.30.

Maybe you had v2 or it was the patches that landed between
kvm-x86-next-2025.09.30 and the current tip of kvm-x86/next?

> In the future, please provide a link to a git repo+branch when posting
> series with dependencies.  It took me several attempts and a bit of conflict
> resolution to get this series applied.

Yeah I can do that, although I think it wouldn't have helped in this
case as the same conflicts would apply. Perhaps mentioning that this is
based on kvm-x86-next-2025.09.30 would have helped?

> 
> > [1]https://lore.kernel.org/kvm/20251001145816.1414855-1-yosry.ahmed@linux.dev/
> > [2]https://lore.kernel.org/kvm/20251009223153.3344555-1-jmattson@google.com/
> > [3]https://lore.kernel.org/kvm/20250917215031.2567566-1-jmattson@google.com/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ