linux-kernel - Re: [Xen-devel] [PATCH] xen-evtchn: Bind dyn evtchn:qemu-dm interrupt to next online VCPU

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 5 Jun 2017 17:14:34 +0100
From:   Anoob Soman <anoob.soman@...rix.com>
To:     Boris Ostrovsky <boris.ostrovsky@...cle.com>,
        <xen-devel@...ts.xenproject.org>, <linux-kernel@...r.kernel.org>
CC:     <jgross@...e.com>
Subject: Re: [Xen-devel] [PATCH] xen-evtchn: Bind dyn evtchn:qemu-dm interrupt
 to next online VCPU

On 05/06/17 16:32, Boris Ostrovsky wrote:
> I believe we do need to take affinity into consideration even if the
> chance that it is non-default is small.

Agreed.

> I am not opposed to having bind_last_selected_cpu percpu, I just wanted
> to understand the reason better. Additional locking would be a downside
> with a global so if you feel that percpu is worth it then I won't object.

If affinity == cpu_online_mask, then percpu will give a better spread. 
atomic set/get can be used, if we want to use a global variable, but I 
think it will be more random than percpu.

>
>> Yes, you are correct. .irq_set_affinity pretty much does the same thing.
>>
>> The code will now looks like this.
>> raw_spin_lock_irqsave(lock, flags);
>> percpu read
>> select_cpu
>> percpu write
>> xen_rebind_evtchn_to_cpu(evtchn, selected_cpu)
>> raw_spin_unlock_irqsave(lock, flags);
> (BTW, I just noticed --- you don't need to initialize desc)

Sorry, I didn't get it. Which desc doesn't need init ?

-Anoob