| Message ID | 1460730231-1184-14-git-send-email-alex.bennee@linaro.org |
|---|---|
| State | New |
| Headers | show |
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
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
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 --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)
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