[PATCH] x86emul: keep compiler from using {x, y, z}mm registers itself

[PATCH] x86emul: keep compiler from using {x, y, z}mm registers itself

[Jan Beulich]

Since the emulator acts on the live hardware registers, we need to
prevent the compiler from using them e.g. for inlined memcpy() /
memset() (as gcc7 does). We can't, however, set this from the command
line, as otherwise the 64-bit build would face issues with functions
returning floating point values and being declared in standard headers.

As the pragma isn't available prior to gcc6, we need to invoke it
conditionally. Luckily up to gcc6 we haven't seen generated code access
SIMD registers beyond what our asm()s do.

Reported-by: George Dunlap <george.dunlap@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
While this doesn't affect core functionality, I think it would still be
nice for it to be allowed in for 4.10.

--- a/tools/tests/x86_emulator/x86-emulate.h
+++ b/tools/tests/x86_emulator/x86-emulate.h
@@ -4,6 +4,11 @@
 #include <stdint.h>
 #include <stdlib.h>
 #include <string.h>
+
+#if __GNUC__ >= 6
+#pragma GCC target("no-sse")
+#endif
+
 #include <xen/xen.h>
 
 #include <asm/msr-index.h>




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH] x86emul: keep compiler from using {x, y, z}mm registers itself

[Andrew Cooper]

On 16/10/17 13:32, Jan Beulich wrote:
> Since the emulator acts on the live hardware registers, we need to
> prevent the compiler from using them e.g. for inlined memcpy() /
> memset() (as gcc7 does). We can't, however, set this from the command
> line, as otherwise the 64-bit build would face issues with functions
> returning floating point values and being declared in standard headers.
>
> As the pragma isn't available prior to gcc6, we need to invoke it
> conditionally. Luckily up to gcc6 we haven't seen generated code access
> SIMD registers beyond what our asm()s do.
>
> Reported-by: George Dunlap <george.dunlap@citrix.com>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> ---
> While this doesn't affect core functionality, I think it would still be
> nice for it to be allowed in for 4.10.

Agreed.

Has this been tested with Clang?  It stands a good chance of being
compatible, but we may need an && !defined(__clang__) included.

~Andrew

>
> --- a/tools/tests/x86_emulator/x86-emulate.h
> +++ b/tools/tests/x86_emulator/x86-emulate.h
> @@ -4,6 +4,11 @@
>  #include <stdint.h>
>  #include <stdlib.h>
>  #include <string.h>
> +
> +#if __GNUC__ >= 6
> +#pragma GCC target("no-sse")
> +#endif
> +
>  #include <xen/xen.h>
>  
>  #include <asm/msr-index.h>
>
>
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH] x86emul: keep compiler from using {x, y, z}mm registers itself

[Jan Beulich]

>>> On 16.10.17 at 14:37, <andrew.cooper3@citrix.com> wrote:
> On 16/10/17 13:32, Jan Beulich wrote:
>> Since the emulator acts on the live hardware registers, we need to
>> prevent the compiler from using them e.g. for inlined memcpy() /
>> memset() (as gcc7 does). We can't, however, set this from the command
>> line, as otherwise the 64-bit build would face issues with functions
>> returning floating point values and being declared in standard headers.
>>
>> As the pragma isn't available prior to gcc6, we need to invoke it
>> conditionally. Luckily up to gcc6 we haven't seen generated code access
>> SIMD registers beyond what our asm()s do.
>>
>> Reported-by: George Dunlap <george.dunlap@citrix.com>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>> ---
>> While this doesn't affect core functionality, I think it would still be
>> nice for it to be allowed in for 4.10.
> 
> Agreed.
> 
> Has this been tested with Clang?

Sorry, no - still haven't got around to set up a suitable Clang
locally.

>  It stands a good chance of being
> compatible, but we may need an && !defined(__clang__) included.

Should non-gcc silently ignore "#pragma GCC ..." it doesn't
recognize, or not define __GNUC__ in the first place if it isn't
sufficiently compatible? I.e. if anything I'd expect we need
"#elif defined(__clang__)" to achieve the same for Clang by
some different pragma (if such exists).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH] x86emul: keep compiler from using {x, y, z}mm registers itself

[George Dunlap]

On 10/16/2017 01:32 PM, Jan Beulich wrote:
> Since the emulator acts on the live hardware registers, we need to
> prevent the compiler from using them e.g. for inlined memcpy() /
> memset() (as gcc7 does). 

Why doesn't this affect the rest of the hypervisor too, since we don't
save and restore the *mm registers?

> We can't, however, set this from the command
> line, as otherwise the 64-bit build would face issues with functions
> returning floating point values and being declared in standard headers.

Sorry, just to clarify: You mean that there are standard headers which
contain prototypes for functions which return floating point values; we
include those headers but do not call the functions; and adding the
#pragma to the command-line would cause the compiler to choke on the
prototypes (even though the functions are never actually called)?

 -George


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH] x86emul: keep compiler from using {x, y, z}mm registers itself

[Jan Beulich]

>>> On 16.10.17 at 17:05, <george.dunlap@citrix.com> wrote:
> On 10/16/2017 01:32 PM, Jan Beulich wrote:
>> Since the emulator acts on the live hardware registers, we need to
>> prevent the compiler from using them e.g. for inlined memcpy() /
>> memset() (as gcc7 does). 
> 
> Why doesn't this affect the rest of the hypervisor too, since we don't
> save and restore the *mm registers?

Because we build the hypervisor with -mno-sse.

>> We can't, however, set this from the command
>> line, as otherwise the 64-bit build would face issues with functions
>> returning floating point values and being declared in standard headers.
> 
> Sorry, just to clarify: You mean that there are standard headers which
> contain prototypes for functions which return floating point values; we
> include those headers but do not call the functions; and adding the
> #pragma to the command-line would cause the compiler to choke on the
> prototypes (even though the functions are never actually called)?

Yes (adding the command line option equivalent of the pragma,
that is).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Ping: [PATCH] x86emul: keep compiler from using {x, y, z}mm registers itself

[Jan Beulich]

>>> On 16.10.17 at 14:42,  wrote:
>>>> On 16.10.17 at 14:37, <andrew.cooper3@citrix.com> wrote:
> > On 16/10/17 13:32, Jan Beulich wrote:
> >> Since the emulator acts on the live hardware registers, we need to
> >> prevent the compiler from using them e.g. for inlined memcpy() /
> >> memset() (as gcc7 does). We can't, however, set this from the command
> >> line, as otherwise the 64-bit build would face issues with functions
> >> returning floating point values and being declared in standard headers.
> >>
> >> As the pragma isn't available prior to gcc6, we need to invoke it
> >> conditionally. Luckily up to gcc6 we haven't seen generated code access
> >> SIMD registers beyond what our asm()s do.
> >>
> >> Reported-by: George Dunlap <george.dunlap@citrix.com>
> >> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> >> ---
> >> While this doesn't affect core functionality, I think it would still be
> >> nice for it to be allowed in for 4.10.
> > 
> > Agreed.
> > 
> > Has this been tested with Clang?
> 
> Sorry, no - still haven't got around to set up a suitable Clang
> locally.
> 
> >  It stands a good chance of being
> > compatible, but we may need an && !defined(__clang__) included.
> 
> Should non-gcc silently ignore "#pragma GCC ..." it doesn't
> recognize, or not define __GNUC__ in the first place if it isn't
> sufficiently compatible? I.e. if anything I'd expect we need
> "#elif defined(__clang__)" to achieve the same for Clang by
> some different pragma (if such exists).

Not having received any reply so far, I'm wondering whether
being able to build the test harness with clang is more
important than for it to work correctly when built with gcc. I
can't predict when I would get around to set up a suitable
clang on my dev systems.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: Ping: [PATCH] x86emul: keep compiler from using {x, y, z}mm registers itself

[George Dunlap]

On 11/06/2017 11:59 AM, Jan Beulich wrote:
>>>> On 16.10.17 at 14:42,  wrote:
>>>>> On 16.10.17 at 14:37, <andrew.cooper3@citrix.com> wrote:
>>> On 16/10/17 13:32, Jan Beulich wrote:
>>>> Since the emulator acts on the live hardware registers, we need to
>>>> prevent the compiler from using them e.g. for inlined memcpy() /
>>>> memset() (as gcc7 does). We can't, however, set this from the command
>>>> line, as otherwise the 64-bit build would face issues with functions
>>>> returning floating point values and being declared in standard headers.
>>>>
>>>> As the pragma isn't available prior to gcc6, we need to invoke it
>>>> conditionally. Luckily up to gcc6 we haven't seen generated code access
>>>> SIMD registers beyond what our asm()s do.
>>>>
>>>> Reported-by: George Dunlap <george.dunlap@citrix.com>
>>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>>> ---
>>>> While this doesn't affect core functionality, I think it would still be
>>>> nice for it to be allowed in for 4.10.
>>>
>>> Agreed.
>>>
>>> Has this been tested with Clang?
>>
>> Sorry, no - still haven't got around to set up a suitable Clang
>> locally.
>>
>>>  It stands a good chance of being
>>> compatible, but we may need an && !defined(__clang__) included.
>>
>> Should non-gcc silently ignore "#pragma GCC ..." it doesn't
>> recognize, or not define __GNUC__ in the first place if it isn't
>> sufficiently compatible? I.e. if anything I'd expect we need
>> "#elif defined(__clang__)" to achieve the same for Clang by
>> some different pragma (if such exists).
> 
> Not having received any reply so far, I'm wondering whether
> being able to build the test harness with clang is more
> important than for it to work correctly when built with gcc. I
> can't predict when I would get around to set up a suitable
> clang on my dev systems.

I agree with the argument you make above.  On the unlikely chance
there's a problem Travis should catch it, and someone who actually has a
clang setup can help sort it out.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: Ping: [PATCH] x86emul: keep compiler from using {x, y, z}mm registers itself

[Julien Grall]

Hi,

On 11/06/2017 03:04 PM, George Dunlap wrote:
> On 11/06/2017 11:59 AM, Jan Beulich wrote:
>>>>> On 16.10.17 at 14:42,  wrote:
>>>>>> On 16.10.17 at 14:37, <andrew.cooper3@citrix.com> wrote:
>>>> On 16/10/17 13:32, Jan Beulich wrote:
>>>>> Since the emulator acts on the live hardware registers, we need to
>>>>> prevent the compiler from using them e.g. for inlined memcpy() /
>>>>> memset() (as gcc7 does). We can't, however, set this from the command
>>>>> line, as otherwise the 64-bit build would face issues with functions
>>>>> returning floating point values and being declared in standard headers.
>>>>>
>>>>> As the pragma isn't available prior to gcc6, we need to invoke it
>>>>> conditionally. Luckily up to gcc6 we haven't seen generated code access
>>>>> SIMD registers beyond what our asm()s do.
>>>>>
>>>>> Reported-by: George Dunlap <george.dunlap@citrix.com>
>>>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>>>> ---
>>>>> While this doesn't affect core functionality, I think it would still be
>>>>> nice for it to be allowed in for 4.10.
>>>>
>>>> Agreed.
>>>>
>>>> Has this been tested with Clang?
>>>
>>> Sorry, no - still haven't got around to set up a suitable Clang
>>> locally.
>>>
>>>>   It stands a good chance of being
>>>> compatible, but we may need an && !defined(__clang__) included.
>>>
>>> Should non-gcc silently ignore "#pragma GCC ..." it doesn't
>>> recognize, or not define __GNUC__ in the first place if it isn't
>>> sufficiently compatible? I.e. if anything I'd expect we need
>>> "#elif defined(__clang__)" to achieve the same for Clang by
>>> some different pragma (if such exists).
>>
>> Not having received any reply so far, I'm wondering whether
>> being able to build the test harness with clang is more
>> important than for it to work correctly when built with gcc. I
>> can't predict when I would get around to set up a suitable
>> clang on my dev systems.
> 
> I agree with the argument you make above.  On the unlikely chance
> there's a problem Travis should catch it, and someone who actually has a
> clang setup can help sort it out.

I am not entirely sure whether this count for a ack or not?

I was waiting an Acked-by/Reviewed-by before consider the Release-Acked-by.

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Ping#2: [PATCH] x86emul: keep compiler from using {x, y, z}mm registers itself

[Jan Beulich]

>>> On 06.11.17 at 16:04, <george.dunlap@citrix.com> wrote:
> On 11/06/2017 11:59 AM, Jan Beulich wrote:
>>>>> On 16.10.17 at 14:42,  wrote:
>>>>>> On 16.10.17 at 14:37, <andrew.cooper3@citrix.com> wrote:
>>>> On 16/10/17 13:32, Jan Beulich wrote:
>>>>> Since the emulator acts on the live hardware registers, we need to
>>>>> prevent the compiler from using them e.g. for inlined memcpy() /
>>>>> memset() (as gcc7 does). We can't, however, set this from the command
>>>>> line, as otherwise the 64-bit build would face issues with functions
>>>>> returning floating point values and being declared in standard headers.
>>>>>
>>>>> As the pragma isn't available prior to gcc6, we need to invoke it
>>>>> conditionally. Luckily up to gcc6 we haven't seen generated code access
>>>>> SIMD registers beyond what our asm()s do.
>>>>>
>>>>> Reported-by: George Dunlap <george.dunlap@citrix.com>
>>>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>>>> ---
>>>>> While this doesn't affect core functionality, I think it would still be
>>>>> nice for it to be allowed in for 4.10.
>>>>
>>>> Agreed.
>>>>
>>>> Has this been tested with Clang?
>>>
>>> Sorry, no - still haven't got around to set up a suitable Clang
>>> locally.
>>>
>>>>  It stands a good chance of being
>>>> compatible, but we may need an && !defined(__clang__) included.
>>>
>>> Should non-gcc silently ignore "#pragma GCC ..." it doesn't
>>> recognize, or not define __GNUC__ in the first place if it isn't
>>> sufficiently compatible? I.e. if anything I'd expect we need
>>> "#elif defined(__clang__)" to achieve the same for Clang by
>>> some different pragma (if such exists).
>> 
>> Not having received any reply so far, I'm wondering whether
>> being able to build the test harness with clang is more
>> important than for it to work correctly when built with gcc. I
>> can't predict when I would get around to set up a suitable
>> clang on my dev systems.
> 
> I agree with the argument you make above.  On the unlikely chance
> there's a problem Travis should catch it, and someone who actually has a
> clang setup can help sort it out.

I'm still lacking an ack, before it being sensible to check with Julien
whether this is still fine to go in at this late stage.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: Ping#2: [PATCH] x86emul: keep compiler from using {x, y, z}mm registers itself

[Andrew Cooper]

On 21/11/17 13:26, Jan Beulich wrote:
>>>> On 06.11.17 at 16:04, <george.dunlap@citrix.com> wrote:
>> On 11/06/2017 11:59 AM, Jan Beulich wrote:
>>>>>> On 16.10.17 at 14:42,  wrote:
>>>>>>> On 16.10.17 at 14:37, <andrew.cooper3@citrix.com> wrote:
>>>>> On 16/10/17 13:32, Jan Beulich wrote:
>>>>>> Since the emulator acts on the live hardware registers, we need to
>>>>>> prevent the compiler from using them e.g. for inlined memcpy() /
>>>>>> memset() (as gcc7 does). We can't, however, set this from the command
>>>>>> line, as otherwise the 64-bit build would face issues with functions
>>>>>> returning floating point values and being declared in standard headers.
>>>>>>
>>>>>> As the pragma isn't available prior to gcc6, we need to invoke it
>>>>>> conditionally. Luckily up to gcc6 we haven't seen generated code access
>>>>>> SIMD registers beyond what our asm()s do.
>>>>>>
>>>>>> Reported-by: George Dunlap <george.dunlap@citrix.com>
>>>>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>>>>> ---
>>>>>> While this doesn't affect core functionality, I think it would still be
>>>>>> nice for it to be allowed in for 4.10.
>>>>> Agreed.
>>>>>
>>>>> Has this been tested with Clang?
>>>> Sorry, no - still haven't got around to set up a suitable Clang
>>>> locally.
>>>>
>>>>>  It stands a good chance of being
>>>>> compatible, but we may need an && !defined(__clang__) included.
>>>> Should non-gcc silently ignore "#pragma GCC ..." it doesn't
>>>> recognize, or not define __GNUC__ in the first place if it isn't
>>>> sufficiently compatible? I.e. if anything I'd expect we need
>>>> "#elif defined(__clang__)" to achieve the same for Clang by
>>>> some different pragma (if such exists).
>>> Not having received any reply so far, I'm wondering whether
>>> being able to build the test harness with clang is more
>>> important than for it to work correctly when built with gcc. I
>>> can't predict when I would get around to set up a suitable
>>> clang on my dev systems.
>> I agree with the argument you make above.  On the unlikely chance
>> there's a problem Travis should catch it, and someone who actually has a
>> clang setup can help sort it out.
> I'm still lacking an ack, before it being sensible to check with Julien
> whether this is still fine to go in at this late stage.

Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: Ping#2: [PATCH] x86emul: keep compiler from using {x, y, z}mm registers itself

[Julien Grall]

Hi,

On 11/21/2017 01:29 PM, Andrew Cooper wrote:
> On 21/11/17 13:26, Jan Beulich wrote:
>>>>> On 06.11.17 at 16:04, <george.dunlap@citrix.com> wrote:
>>> On 11/06/2017 11:59 AM, Jan Beulich wrote:
>>>>>>> On 16.10.17 at 14:42,  wrote:
>>>>>>>> On 16.10.17 at 14:37, <andrew.cooper3@citrix.com> wrote:
>>>>>> On 16/10/17 13:32, Jan Beulich wrote:
>>>>>>> Since the emulator acts on the live hardware registers, we need to
>>>>>>> prevent the compiler from using them e.g. for inlined memcpy() /
>>>>>>> memset() (as gcc7 does). We can't, however, set this from the command
>>>>>>> line, as otherwise the 64-bit build would face issues with functions
>>>>>>> returning floating point values and being declared in standard headers.
>>>>>>>
>>>>>>> As the pragma isn't available prior to gcc6, we need to invoke it
>>>>>>> conditionally. Luckily up to gcc6 we haven't seen generated code access
>>>>>>> SIMD registers beyond what our asm()s do.
>>>>>>>
>>>>>>> Reported-by: George Dunlap <george.dunlap@citrix.com>
>>>>>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>>>>>> ---
>>>>>>> While this doesn't affect core functionality, I think it would still be
>>>>>>> nice for it to be allowed in for 4.10.
>>>>>> Agreed.
>>>>>>
>>>>>> Has this been tested with Clang?
>>>>> Sorry, no - still haven't got around to set up a suitable Clang
>>>>> locally.
>>>>>
>>>>>>   It stands a good chance of being
>>>>>> compatible, but we may need an && !defined(__clang__) included.
>>>>> Should non-gcc silently ignore "#pragma GCC ..." it doesn't
>>>>> recognize, or not define __GNUC__ in the first place if it isn't
>>>>> sufficiently compatible? I.e. if anything I'd expect we need
>>>>> "#elif defined(__clang__)" to achieve the same for Clang by
>>>>> some different pragma (if such exists).
>>>> Not having received any reply so far, I'm wondering whether
>>>> being able to build the test harness with clang is more
>>>> important than for it to work correctly when built with gcc. I
>>>> can't predict when I would get around to set up a suitable
>>>> clang on my dev systems.
>>> I agree with the argument you make above.  On the unlikely chance
>>> there's a problem Travis should catch it, and someone who actually has a
>>> clang setup can help sort it out.
>> I'm still lacking an ack, before it being sensible to check with Julien
>> whether this is still fine to go in at this late stage.

I would be happy with that.

Release-acked-by: Julien Grall <julien.grall@linaro.org>

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel