Re: [PATCH v10 16/19] KVM: xen: split up kvm_xen_set_evtchn_fast()

From: David Woodhouse <dwmw2@infradead.org>
To: Paul Durrant <paul@xen.org>, Paolo Bonzini <pbonzini@redhat.com>,
	 Jonathan Corbet <corbet@lwn.net>,
	Sean Christopherson <seanjc@google.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	Shuah Khan <shuah@kernel.org>,
	kvm@vger.kernel.org,  linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org,  linux-kselftest@vger.kernel.org
Subject: Re: [PATCH v10 16/19] KVM: xen: split up kvm_xen_set_evtchn_fast()
Date: Thu, 14 Dec 2023 14:00:16 +0000	[thread overview]
Message-ID: <e22e354305d853d72039c7e12b166410de3f63c9.camel@infradead.org> (raw)
In-Reply-To: <20231204144334.910-17-paul@xen.org>

[-- Attachment #1: Type: text/plain, Size: 2835 bytes --]

On Mon, 2023-12-04 at 14:43 +0000, Paul Durrant wrote:
> From: Paul Durrant <pdurrant@amazon.com>
> 
> The implementation of kvm_xen_set_evtchn_fast() is a rather lengthy piece
> of code that performs two operations: updating of the shared_info
> evtchn_pending mask, and updating of the vcpu_info evtchn_pending_sel
> mask. Introduce a separate function to perform each of those operations and
> re-work kvm_xen_set_evtchn_fast() to use them.
> 
> No functional change intended.
> 
> Signed-off-by: Paul Durrant <pdurrant@amazon.com>

...

> +       if (IS_ENABLED(CONFIG_64BIT) && kvm->arch.xen.long_mode) {
> +               struct vcpu_info *vcpu_info = gpc->khva;
> +               u32 port_word_bit = port / 32;

Shouldn't that one be /64, and the compat one be /32?

> +
> +               if (!kvm_gpc_check(gpc, sizeof(*vcpu_info))) {
> +                       if (!test_and_set_bit(port_word_bit, &vcpu->arch.xen.evtchn_pending_sel))
> +                               kick_vcpu = true;
> +                       goto out;
> +               }
> +
> +               if (!test_and_set_bit(port_word_bit, &vcpu_info->evtchn_pending_sel)) {
> +                       WRITE_ONCE(vcpu_info->evtchn_upcall_pending, 1);
> +                       kick_vcpu = true;

This is the one you're removing...

> -       int port_word_bit;

...

> -       if (IS_ENABLED(CONFIG_64BIT) && kvm->arch.xen.long_mode) {
> -               struct shared_info *shinfo = gpc->khva;
> -               pending_bits = (unsigned long *)&shinfo->evtchn_pending;
> -               mask_bits = (unsigned long *)&shinfo->evtchn_mask;
> -               port_word_bit = xe->port / 64;
> -       } else {
> -               struct compat_shared_info *shinfo = gpc->khva;
> -               pending_bits = (unsigned long *)&shinfo->evtchn_pending;
> -               mask_bits = (unsigned long *)&shinfo->evtchn_mask;
> -               port_word_bit = xe->port / 32;
> -       }

And why change it from an int to a u32? 

On x86, arch_test_and_set_bit() takes a 'long' as its first argument,
and arch___test_and_set_bit takes an 'unsigned long'.
Then again, asm-generic/bitops/atomic.h has an arch_test_and_set_bit()
taking an 'unsigned int'. And the le version takes an 'int'.

My brain hurts. That's a complete clusterfuck and none of it seems to
have any commentary about why.

Either way, *none* of them take a u32. Why did you change to that
instead of leaving well alone? I now blame you for my headache :)

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5965 bytes --]