Linux Virtualization - Feb 2017 - [PATCH v4 1/2] x86/paravirt: Change vcp_is_preempted() arg type to long

On Wed, Feb 15, 2017 at 04:37:49PM -0500, Waiman Long
wrote:
> The cpu argument in the function prototype of vcpu_is_preempted()
> is changed from int to long. That makes it easier to provide a better
> optimized assembly version of that function.
> 
> For Xen, vcpu_is_preempted(long) calls xen_vcpu_stolen(int), the
> downcast from long to int is not a problem as vCPU number won't exceed
> 32 bits.
> 
Note that because of the cast in PVOP_CALL_ARG1() this patch is
pointless.

Then again, it doesn't seem to affect code generation, so why not. Takes
away the reliance on that weird cast.

On 02/16/2017 11:09 AM, Peter Zijlstra wrote:
> On Wed, Feb 15, 2017 at 04:37:49PM -0500, Waiman Long wrote:
>> The cpu argument in the function prototype of vcpu_is_preempted()
>> is changed from int to long. That makes it easier to provide a better
>> optimized assembly version of that function.
>>
>> For Xen, vcpu_is_preempted(long) calls xen_vcpu_stolen(int), the
>> downcast from long to int is not a problem as vCPU number won't
exceed
>> 32 bits.
>>
> Note that because of the cast in PVOP_CALL_ARG1() this patch is
> pointless.
>
> Then again, it doesn't seem to affect code generation, so why not.
Takes
> away the reliance on that weird cast.
I add this patch because I am a bit uneasy about clearing the upper 32
bits of rdi and assuming that the compiler won't have a previous use of
those bits. It gives me peace of mind.

Cheers,
Longman

On Thu, Feb 16, 2017 at 04:02:57PM -0500, Waiman Long
wrote:
> On 02/16/2017 11:09 AM, Peter Zijlstra wrote:
> > On Wed, Feb 15, 2017 at 04:37:49PM -0500, Waiman Long wrote:
> >> The cpu argument in the function prototype of vcpu_is_preempted()
> >> is changed from int to long. That makes it easier to provide a
better
> >> optimized assembly version of that function.
> >>
> >> For Xen, vcpu_is_preempted(long) calls xen_vcpu_stolen(int), the
> >> downcast from long to int is not a problem as vCPU number
won't exceed
> >> 32 bits.
> >>
> > Note that because of the cast in PVOP_CALL_ARG1() this patch is
> > pointless.
> >
> > Then again, it doesn't seem to affect code generation, so why not.
Takes
> > away the reliance on that weird cast.
> 
> I add this patch because I am a bit uneasy about clearing the upper 32
> bits of rdi and assuming that the compiler won't have a previous use of
> those bits. It gives me peace of mind.
So currently the PVOP_CALL_ARG#() macros force cast everything to
(unsigned long) anyway, but it would be good not to rely on that I
think, so yes.