linux-kernel - Re: [GIT PULL] KVM: Generic changes for 6.20

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: <CABgObfbKh1Tbzv63GfopW3KQhYtfAGgXXBgGn6EiR2kSBgH_jA@mail.gmail.com>
Date: Mon, 9 Feb 2026 18:42:03 +0100
From: Paolo Bonzini <pbonzini@...hat.com>
To: Sean Christopherson <seanjc@...gle.com>
Cc: kvm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] KVM: Generic changes for 6.20

On Mon, Feb 9, 2026 at 6:38 PM Paolo Bonzini <pbonzini@...hat.com> wrote:
>
> On Sat, Feb 7, 2026 at 5:10 AM Sean Christopherson <seanjc@...gle.com> wrote:
> >  - Document that vcpu->mutex is take outside of kvm->slots_lock, which is all
> >    kinds of unintuitive, but is unfortunately the existing behavior for
> >    multiple architectures, and in a weird way actually makes sense.
>
> I disagree that it is "arguably wrong" how you put it in the commit
> message. vcpu->mutex is really a "don't worry about multiple ioctls at
> the same time" mutex that tries to stay out of the way.  It only
> becomes unintuitive in special cases like
> tdx_acquire_vm_state_locks().
>
> By itself this would not be a reason to resend, but while at it you
> could mention that vcpu->mutex is taken outside kvm->slots_arch_lock?

... as well as mention kvm_alloc_apic_access_page() in the commit message.

Paolo