linux-kernel - Re: [PATCH 07/20] KVM: selftests: Continuously reap dirty ring while vCPU is running

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: <Z2N7zN7252_85ttO@google.com>
Date: Wed, 18 Dec 2024 17:50:04 -0800
From: Sean Christopherson <seanjc@...gle.com>
To: Maxim Levitsky <mlevitsk@...hat.com>
Cc: Paolo Bonzini <pbonzini@...hat.com>, kvm@...r.kernel.org, linux-kernel@...r.kernel.org, 
	Peter Xu <peterx@...hat.com>
Subject: Re: [PATCH 07/20] KVM: selftests: Continuously reap dirty ring while
 vCPU is running

On Tue, Dec 17, 2024, Maxim Levitsky wrote:
> On Fri, 2024-12-13 at 17:07 -0800, Sean Christopherson wrote:
> > When running dirty_log_test using the dirty ring, post to sem_vcpu_stop
> > only when the main thread has explicitly requested that the vCPU stop.
> > Synchronizing the vCPU and main thread whenever the dirty ring happens to
> > be full is unnecessary, as KVM's ABI is to actively prevent the vCPU from
> > running until the ring is no longer full.  I.e. attempting to run the vCPU
> > will simply result in KVM_EXIT_DIRTY_RING_FULL without ever entering the
> > guest.  And if KVM doesn't exit, e.g. let's the vCPU dirty more pages,
> > then that's a KVM bug worth finding.
> 
> This is probably a good idea to do sometimes, but this can also reduce
> coverage because now the vCPU will pointlessly enter and exit when dirty log
> is full.

But the alternative is simply waiting in host userspace.  I agree that doing
KVM_RUN when it's guaranteed to get hairpinned back to userspace isn't all that
interesting, but it's arguably better than having that task scheduled out while
waiting for the main thread, and I definitely don't think it's any worse.