linux-kernel - Re: [PATCH 3/3] KVM: s390: Use generic VIRT_XFER_TO_GUEST

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: <20251125111618.10410Fa0-hca@linux.ibm.com>
Date: Tue, 25 Nov 2025 12:16:18 +0100
From: Heiko Carstens <hca@...ux.ibm.com>
To: Andrew Donnellan <ajd@...ux.ibm.com>
Cc: kvm@...r.kernel.org, linux-s390@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Christian Borntraeger <borntraeger@...ux.ibm.com>,
        Janosch Frank <frankja@...ux.ibm.com>,
        Claudio Imbrenda <imbrenda@...ux.ibm.com>,
        Vasily Gorbik <gor@...ux.ibm.com>,
        Alexander Gordeev <agordeev@...ux.ibm.com>,
        Sven Schnelle <svens@...ux.ibm.com>,
        Nicholas Miehlbradt <nicholas@...ux.ibm.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Peter Zijlstra <peterz@...radead.org>,
        Andy Lutomirski <luto@...nel.org>,
        David Hildenbrand <david@...nel.org>
Subject: Re: [PATCH 3/3] KVM: s390: Use generic VIRT_XFER_TO_GUEST_WORK
 functions

On Tue, Nov 25, 2025 at 06:45:54PM +1100, Andrew Donnellan wrote:
> Switch to using the generic infrastructure to check for and handle pending
> work before transitioning into guest mode.
> 
> xfer_to_guest_mode_handle_work() does a few more things than the current
> code does when deciding whether or not to exit the __vcpu_run() loop. The
> exittime tests from kvm-unit-tests, in my tests, were +/-3% compared to
> before this series, which is within noise tolerance.

...

>  		local_irq_disable();
> +
> +		xfer_to_guest_mode_prepare();
> +		if (xfer_to_guest_mode_work_pending()) {
> +			local_irq_enable();
> +			rc = kvm_xfer_to_guest_mode_handle_work(vcpu);
> +			if (rc)
> +				break;
> +			local_irq_disable();
> +		}
> +
>  		guest_timing_enter_irqoff();
>  		__disable_cpu_timer_accounting(vcpu);

This looks racy: kvm_xfer_to_guest_mode_handle_work() returns with
interrupts enabled and before interrupts are disabled again more work
might have been become pending. But that is ignored and guest state is
entered instead. Why not change the above simply to something like
this to avoid this:

again:
	local_irq_disable();
		xfer_to_guest_mode_prepare();
		if (xfer_to_guest_mode_work_pending()) {
			local_irq_enable();
			rc = kvm_xfer_to_guest_mode_handle_work(vcpu);
			if (rc)
				break;
			goto again;
		}

		guest_timing_enter_irqoff();
		__disable_cpu_timer_accounting(vcpu);

But maybe I'm missing something?

> @@ -1181,11 +1181,21 @@ static int do_vsie_run(struct kvm_vcpu *vcpu, struct vsie_page *vsie_page)
>  	barrier();
>  	if (!kvm_s390_vcpu_sie_inhibited(vcpu)) {
>  		local_irq_disable();
> +		xfer_to_guest_mode_prepare();
> +		if (xfer_to_guest_mode_work_pending()) {
> +			local_irq_enable();
> +			rc = kvm_xfer_to_guest_mode_handle_work(vcpu);
> +			if (rc)
> +				goto skip_sie;
> +			local_irq_disable();
> +		}
>  		guest_timing_enter_irqoff();
>  		rc = kvm_s390_enter_exit_sie(scb_s, vcpu->run->s.regs.gprs, vsie_page->gmap->asce);

Same here.