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] [day] [month] [year] [list]

Message-ID: <aYp86UFynnoBLy3m@google.com>
Date: Mon, 9 Feb 2026 16:33:45 -0800
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: Generic changes for 6.20

On Mon, Feb 09, 2026, Paolo Bonzini wrote:
> 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.

Ya, will do.