diff mbox

[RFC,v1,12/12] cpus: default MTTCG to on for 32 bit ARM on x86

Message ID 1460730231-1184-14-git-send-email-alex.bennee@linaro.org
State New
Headers show

Commit Message

Alex Bennée April 15, 2016, 2:23 p.m. UTC
This makes multi-threading the default for 32 bit ARM on x86. It has
been tested with Debian Jessie as well as my extended KVM unit tests
which stress the SMC and TB invalidation code. Those tests can be found
at:

  https://github.com/stsquad/kvm-unit-tests/tree/mttcg/current-tests-v5

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>

---
 cpus.c | 20 ++++++++++++++++----
 1 file changed, 16 insertions(+), 4 deletions(-)

-- 
2.7.4

Comments

Peter Maydell June 6, 2016, 10:26 a.m. UTC | #1
On 15 April 2016 at 15:23, Alex Bennée <alex.bennee@linaro.org> wrote:
> This makes multi-threading the default for 32 bit ARM on x86. It has

> been tested with Debian Jessie as well as my extended KVM unit tests

> which stress the SMC and TB invalidation code. Those tests can be found

> at:

>

>   https://github.com/stsquad/kvm-unit-tests/tree/mttcg/current-tests-v5

>

> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>

> ---

>  cpus.c | 20 ++++++++++++++++----

>  1 file changed, 16 insertions(+), 4 deletions(-)

>

> diff --git a/cpus.c b/cpus.c

> index 860e2a9..daa92c7 100644

> --- a/cpus.c

> +++ b/cpus.c

> @@ -171,12 +171,24 @@ opts_init(tcg_register_config);

>

>  static bool default_mttcg_enabled(void)

>  {

> -    /*

> -     * TODO: Check if we have a chance to have MTTCG working on this guest/host.

> -     *       Basically is the atomic instruction implemented? Is there any

> -     *       memory ordering issue?

> +    /* Checklist for enabling MTTCG on a given frontend/backend combination

> +     *

> +     *  - Are atomics correctly modelled for an MTTCG environment

> +     *  - If the backend is weakly ordered

> +     *    - has the front-end implemented explicit memory ordering ops

> +     *    - does the back-end generate code to ensure memory ordering

>       */

> +#if defined(__i386__) || defined(__x86_64__)

> +    /* x86 backend is strongly ordered which helps a lot */

> +    #if defined(TARGET_ARM)

> +    return true;

> +    #else

> +    return false;

> +    #endif

> +#else

> +    /* Until memory ordering implemented things will likely break */

>      return false;

> +#endif


No new per-host ifdef ladders, please (or per-target ifdef ladders,
either). Have some #defines for "TCG backend supports MTTCG" and
"TCG frontend supports MTTCG" which get set in some suitable per-host
and per-target header, and only enable if they're both set.

thanks
-- PMM
Alex Bennée June 6, 2016, 2:28 p.m. UTC | #2
Peter Maydell <peter.maydell@linaro.org> writes:

> On 15 April 2016 at 15:23, Alex Bennée <alex.bennee@linaro.org> wrote:

>> This makes multi-threading the default for 32 bit ARM on x86. It has

>> been tested with Debian Jessie as well as my extended KVM unit tests

>> which stress the SMC and TB invalidation code. Those tests can be found

>> at:

>>

>>   https://github.com/stsquad/kvm-unit-tests/tree/mttcg/current-tests-v5

>>

>> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>

>> ---

>>  cpus.c | 20 ++++++++++++++++----

>>  1 file changed, 16 insertions(+), 4 deletions(-)

>>

>> diff --git a/cpus.c b/cpus.c

>> index 860e2a9..daa92c7 100644

>> --- a/cpus.c

>> +++ b/cpus.c

>> @@ -171,12 +171,24 @@ opts_init(tcg_register_config);

>>

>>  static bool default_mttcg_enabled(void)

>>  {

>> -    /*

>> -     * TODO: Check if we have a chance to have MTTCG working on this guest/host.

>> -     *       Basically is the atomic instruction implemented? Is there any

>> -     *       memory ordering issue?

>> +    /* Checklist for enabling MTTCG on a given frontend/backend combination

>> +     *

>> +     *  - Are atomics correctly modelled for an MTTCG environment

>> +     *  - If the backend is weakly ordered

>> +     *    - has the front-end implemented explicit memory ordering ops

>> +     *    - does the back-end generate code to ensure memory ordering

>>       */

>> +#if defined(__i386__) || defined(__x86_64__)

>> +    /* x86 backend is strongly ordered which helps a lot */

>> +    #if defined(TARGET_ARM)

>> +    return true;

>> +    #else

>> +    return false;

>> +    #endif

>> +#else

>> +    /* Until memory ordering implemented things will likely break */

>>      return false;

>> +#endif

>

> No new per-host ifdef ladders, please (or per-target ifdef ladders,

> either). Have some #defines for "TCG backend supports MTTCG" and

> "TCG frontend supports MTTCG" which get set in some suitable per-host

> and per-target header, and only enable if they're both set.


Will do so. I guess the middling case of backend is strongly ordered
enough to get away with partial barrier implementation at the front end
should be skipped? We'll only turn on the frontend/backend support flags
when:

  * All frontends fully express the ordering constraints to the TCG
    (e.g. all barriers and annotations complete)

  * The backend emits enough code to ensure any ordering constraint
    expressed in TCG ops can be satisfied.

Are you happy to keep the commentary here with the default function as
that is where people are likely to end up when searching?

>

> thanks

> -- PMM



--
Alex Bennée
Peter Maydell June 6, 2016, 2:37 p.m. UTC | #3
On 6 June 2016 at 15:28, Alex Bennée <alex.bennee@linaro.org> wrote:
> Peter Maydell <peter.maydell@linaro.org> writes:

>> No new per-host ifdef ladders, please (or per-target ifdef ladders,

>> either). Have some #defines for "TCG backend supports MTTCG" and

>> "TCG frontend supports MTTCG" which get set in some suitable per-host

>> and per-target header, and only enable if they're both set.

>

> Will do so. I guess the middling case of backend is strongly ordered

> enough to get away with partial barrier implementation at the front end

> should be skipped?


I don't mind if you have multiple ifdefs for "backend fully supports
MTTCG" and "backend partially supports MTTCG" or whatever combination
makes sense -- I haven't looked enough at the implementation to
know what would be best. I just want to avoid ifdef ladders.

> Are you happy to keep the commentary here with the default function as

> that is where people are likely to end up when searching?


Yes, that makes sense. Consider also a section in tcg/README
documenting the requirements for a backend.

thanks
-- PMM
diff mbox

Patch

diff --git a/cpus.c b/cpus.c
index 860e2a9..daa92c7 100644
--- a/cpus.c
+++ b/cpus.c
@@ -171,12 +171,24 @@  opts_init(tcg_register_config);
 
 static bool default_mttcg_enabled(void)
 {
-    /*
-     * TODO: Check if we have a chance to have MTTCG working on this guest/host.
-     *       Basically is the atomic instruction implemented? Is there any
-     *       memory ordering issue?
+    /* Checklist for enabling MTTCG on a given frontend/backend combination
+     *
+     *  - Are atomics correctly modelled for an MTTCG environment
+     *  - If the backend is weakly ordered
+     *    - has the front-end implemented explicit memory ordering ops
+     *    - does the back-end generate code to ensure memory ordering
      */
+#if defined(__i386__) || defined(__x86_64__)
+    /* x86 backend is strongly ordered which helps a lot */
+    #if defined(TARGET_ARM)
+    return true;
+    #else
+    return false;
+    #endif
+#else
+    /* Until memory ordering implemented things will likely break */
     return false;
+#endif
 }
 
 void qemu_tcg_configure(QemuOpts *opts)