[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e22e354305d853d72039c7e12b166410de3f63c9.camel@infradead.org>
Date: Thu, 14 Dec 2023 14:00:16 +0000
From: David Woodhouse <dwmw2@...radead.org>
To: Paul Durrant <paul@....org>, Paolo Bonzini <pbonzini@...hat.com>,
Jonathan Corbet <corbet@....net>,
Sean Christopherson <seanjc@...gle.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
"H. Peter Anvin" <hpa@...or.com>, Shuah Khan <shuah@...nel.org>,
kvm@...r.kernel.org, linux-doc@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org
Subject: Re: [PATCH v10 16/19] KVM: xen: split up kvm_xen_set_evtchn_fast()
On Mon, 2023-12-04 at 14:43 +0000, Paul Durrant wrote:
> From: Paul Durrant <pdurrant@...zon.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@...zon.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 :)
Download attachment "smime.p7s" of type "application/pkcs7-signature" (5965 bytes)
Powered by blists - more mailing lists