Re: [PATCH v2] x86/paravirt: Don't make vcpu_is_preempted() a callee-save function
From: Waiman Long <longman@redhat.com>
Date: 2017-02-14 14:46:33
Also in:
kvm, linux-arch, lkml
Possibly related (same subject, not in this thread)
- 2017-02-13 · Re: [PATCH v2] x86/paravirt: Don't make vcpu_is_preempted() a callee-save function · Peter Zijlstra <peterz@infradead.org>
- 2017-02-13 · Re: [PATCH v2] x86/paravirt: Don't make vcpu_is_preempted() a callee-save function · Waiman Long <longman@redhat.com>
- 2017-02-13 · Re: [PATCH v2] x86/paravirt: Don't make vcpu_is_preempted() a callee-save function · Peter Zijlstra <peterz@infradead.org>
- 2017-02-13 · Re: [PATCH v2] x86/paravirt: Don't make vcpu_is_preempted() a callee-save function · hpa@zytor.com
- 2017-02-13 · Re: [PATCH v2] x86/paravirt: Don't make vcpu_is_preempted() a callee-save function · Waiman Long <longman@redhat.com>
On 02/14/2017 04:39 AM, Peter Zijlstra wrote:
On Mon, Feb 13, 2017 at 05:34:01PM -0500, Waiman Long wrote:quoted
It is the address of &steal_time that will exceed the 32-bit limit.That seems extremely unlikely. That would mean we have more than 4G worth of per-cpu variables declared in the kernel.
I have some doubt about if the compiler is able to properly use RIP-relative addressing for this. Anyway, it seems like constraints aren't allowed for asm() when not in the function context, at least for the the compiler that I am using (4.8.5). So it is a moot point. Cheers, Longman