linux-kernel - Re: [PATCH v10 16/19] KVM: xen: split up kvm_xen_set_evtchn

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]

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)