On Fri, Dec 09, 2016 at 12:40:35AM +0800, Pan Xinhui wrote:
>
> hi, Peter
> I think I know the point.
>
> then could we just let __eax rettype(here is bool), not unsigned long?
> I does not do tests for my thoughts.
>
> @@ -461,7 +461,9 @@ int paravirt_disable_iospace(void);
> #define
On Fri, Dec 09, 2016 at 12:40:35AM +0800, Pan Xinhui wrote:
>
> hi, Peter
> I think I know the point.
>
> then could we just let __eax rettype(here is bool), not unsigned long?
> I does not do tests for my thoughts.
>
> @@ -461,7 +461,9 @@ int paravirt_disable_iospace(void);
> #define
hi, Peter
I think I know the point.
then could we just let __eax rettype(here is bool), not unsigned long?
I does not do tests for my thoughts.
@@ -461,7 +461,9 @@ int paravirt_disable_iospace(void);
#define PVOP_VCALL_ARGS
\
hi, Peter
I think I know the point.
then could we just let __eax rettype(here is bool), not unsigned long?
I does not do tests for my thoughts.
@@ -461,7 +461,9 @@ int paravirt_disable_iospace(void);
#define PVOP_VCALL_ARGS
\
Commit 3cded4179481 ("x86/paravirt: Optimize native
pv_lock_ops.vcpu_is_preempted()") introduced a paravirt op with bool
return type [*]
It turns out that the PVOP_CALL*() macros miscompile when rettype is
bool. Code that looked like:
83 ef 01sub$0x1,%edi
ff 15 32 a0 d8
Commit 3cded4179481 ("x86/paravirt: Optimize native
pv_lock_ops.vcpu_is_preempted()") introduced a paravirt op with bool
return type [*]
It turns out that the PVOP_CALL*() macros miscompile when rettype is
bool. Code that looked like:
83 ef 01sub$0x1,%edi
ff 15 32 a0 d8
6 matches
Mail list logo