Thread (13 messages) 13 messages, 4 authors, 2017-02-13

Re: [PATCH v2] x86/paravirt: Don't make vcpu_is_preempted() a callee-save function

From: Peter Zijlstra <peterz@infradead.org>
Date: 2017-02-13 21:59:44
Also in: kvm, linux-arch, lkml

On Mon, Feb 13, 2017 at 12:06:44PM -0800, hpa@zytor.com wrote:
quoted
Maybe:

movsql %edi, %rax;
movq __per_cpu_offset(,%rax,8), %rax;
cmpb $0, %[offset](%rax);
setne %al;

?
We could kill the zero or sign extend by changing the calling
interface to pass an unsigned long instead of an int.  It is much more
likely that a zero extend is free for the caller than a sign extend.
Right, Boris and me talked about that on IRC. I was wondering if the
argument was u32 if we could assume the top 32 bits are 0 and then use
rdi without prior movzx.

That would allow reducing the thing one more instruction.

Also, PVOP_CALL_ARG#() have an (unsigned long) cast in them that doesn't
make sense. That cast ends up resulting in the calling code doing
explicit sign or zero extends into the full 64bit register for no good
reason.

If one removes that cast things still compile, but I worry something
somehow relies on this weird behaviour and will come apart.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help