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
| ||
|
Date: Mon, 13 Feb 2017 14:36:36 -0800 From: hpa@...or.com To: Waiman Long <longman@...hat.com>, Peter Zijlstra <peterz@...radead.org> CC: Jeremy Fitzhardinge <jeremy@...p.org>, Chris Wright <chrisw@...s-sol.org>, Alok Kataria <akataria@...are.com>, Rusty Russell <rusty@...tcorp.com.au>, Ingo Molnar <mingo@...hat.com>, Thomas Gleixner <tglx@...utronix.de>, linux-arch@...r.kernel.org, x86@...nel.org, linux-kernel@...r.kernel.org, virtualization@...ts.linux-foundation.org, xen-devel@...ts.xenproject.org, kvm@...r.kernel.org, Pan Xinhui <xinhui.pan@...ux.vnet.ibm.com>, Paolo Bonzini <pbonzini@...hat.com>, Radim Krčmář <rkrcmar@...hat.com>, Boris Ostrovsky <boris.ostrovsky@...cle.com>, Juergen Gross <jgross@...e.com> Subject: Re: [PATCH v2] x86/paravirt: Don't make vcpu_is_preempted() a callee-save function On February 13, 2017 2:34:01 PM PST, Waiman Long <longman@...hat.com> wrote: >On 02/13/2017 04:52 PM, Peter Zijlstra wrote: >> On Mon, Feb 13, 2017 at 03:12:45PM -0500, Waiman Long wrote: >>> On 02/13/2017 02:42 PM, Waiman Long wrote: >>>> On 02/13/2017 05:53 AM, Peter Zijlstra wrote: >>>>> On Mon, Feb 13, 2017 at 11:47:16AM +0100, Peter Zijlstra wrote: >>>>>> That way we'd end up with something like: >>>>>> >>>>>> asm(" >>>>>> push %rdi; >>>>>> movslq %edi, %rdi; >>>>>> movq __per_cpu_offset(,%rdi,8), %rax; >>>>>> cmpb $0, %[offset](%rax); >>>>>> setne %al; >>>>>> pop %rdi; >>>>>> " : : [offset] "i" (((unsigned long)&steal_time) + >offsetof(struct steal_time, preempted))); >>>>>> >>>>>> And if we could get rid of the sign extend on edi we could avoid >all the >>>>>> push-pop nonsense, but I'm not sure I see how to do that (then >again, >>>>>> this asm foo isn't my strongest point). >>>>> Maybe: >>>>> >>>>> movsql %edi, %rax; >>>>> movq __per_cpu_offset(,%rax,8), %rax; >>>>> cmpb $0, %[offset](%rax); >>>>> setne %al; >>>>> >>>>> ? >>>> Yes, that looks good to me. >>>> >>>> Cheers, >>>> Longman >>>> >>> Sorry, I am going to take it back. The displacement or offset can >only >>> be up to 32-bit. So we will still need to use at least one more >>> register, I think. >> I don't think that would be a problem, I very much doubt we declare >more >> than 4G worth of per-cpu variables in the kernel. >> >> In any case, use "e" or "Z" as constraint (I never quite know when to >> use which). That are s32 and u32 displacement immediates resp. and >> should fail compile with a semi-sensible failure if the displacement >is >> too big. >> >It is the address of &steal_time that will exceed the 32-bit limit. > >Cheers, >Longman That seems odd in the extreme? -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Powered by blists - more mailing lists