[PATCH] target/ppc/excp_helper: Take BQL before calling cpu_interrupt()

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[PATCH] target/ppc/excp_helper: Take BQL before calling cpu_interrupt()

Thomas Huth-3
Since the introduction of MTTCG, using the msgsnd instruction
abort()s if being called without holding the BQL. So let's protect
that part of the code now with qemu_mutex_lock_iothread().

Buglink: https://bugs.launchpad.net/qemu/+bug/1694998
Signed-off-by: Thomas Huth <[hidden email]>
---
 target/ppc/excp_helper.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/target/ppc/excp_helper.c b/target/ppc/excp_helper.c
index 9cb2123..3a9f086 100644
--- a/target/ppc/excp_helper.c
+++ b/target/ppc/excp_helper.c
@@ -17,6 +17,7 @@
  * License along with this library; if not, see <http://www.gnu.org/licenses/>.
  */
 #include "qemu/osdep.h"
+#include "qemu/main-loop.h"
 #include "cpu.h"
 #include "exec/helper-proto.h"
 #include "exec/exec-all.h"
@@ -1132,6 +1133,7 @@ void helper_msgsnd(target_ulong rb)
         return;
     }
 
+    qemu_mutex_lock_iothread();
     CPU_FOREACH(cs) {
         PowerPCCPU *cpu = POWERPC_CPU(cs);
         CPUPPCState *cenv = &cpu->env;
@@ -1141,5 +1143,6 @@ void helper_msgsnd(target_ulong rb)
             cpu_interrupt(cs, CPU_INTERRUPT_HARD);
         }
     }
+    qemu_mutex_unlock_iothread();
 }
 #endif
--
1.8.3.1


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PATCH] target/ppc/excp_helper: Take BQL before calling cpu_interrupt()

Alex Bennée-2

Thomas Huth <[hidden email]> writes:

> Since the introduction of MTTCG, using the msgsnd instruction
> abort()s if being called without holding the BQL. So let's protect
> that part of the code now with qemu_mutex_lock_iothread().
>
> Buglink: https://bugs.launchpad.net/qemu/+bug/1694998
> Signed-off-by: Thomas Huth <[hidden email]>

Reviewed-by: Alex Bennée <[hidden email]>

p.s. I was checking the ppc code for other CPU_FOREACH patterns and I
noticed the tlb_flush calls could probably use the tlb_flush_all_cpus
API instead of manually looping themselves. You should also double check
the semantics to make sure none of them need to use the _synced variant
and a cpu_exit if the flush needs to complete w.r.t the originating CPU.

> ---
>  target/ppc/excp_helper.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/target/ppc/excp_helper.c b/target/ppc/excp_helper.c
> index 9cb2123..3a9f086 100644
> --- a/target/ppc/excp_helper.c
> +++ b/target/ppc/excp_helper.c
> @@ -17,6 +17,7 @@
>   * License along with this library; if not, see <http://www.gnu.org/licenses/>.
>   */
>  #include "qemu/osdep.h"
> +#include "qemu/main-loop.h"
>  #include "cpu.h"
>  #include "exec/helper-proto.h"
>  #include "exec/exec-all.h"
> @@ -1132,6 +1133,7 @@ void helper_msgsnd(target_ulong rb)
>          return;
>      }
>
> +    qemu_mutex_lock_iothread();
>      CPU_FOREACH(cs) {
>          PowerPCCPU *cpu = POWERPC_CPU(cs);
>          CPUPPCState *cenv = &cpu->env;
> @@ -1141,5 +1143,6 @@ void helper_msgsnd(target_ulong rb)
>              cpu_interrupt(cs, CPU_INTERRUPT_HARD);
>          }
>      }
> +    qemu_mutex_unlock_iothread();
>  }
>  #endif


--
Alex Bennée

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PATCH] target/ppc/excp_helper: Take BQL before calling cpu_interrupt()

David Gibson
In reply to this post by Thomas Huth-3
On Tue, Jun 13, 2017 at 12:55:29PM +0200, Thomas Huth wrote:
> Since the introduction of MTTCG, using the msgsnd instruction
> abort()s if being called without holding the BQL. So let's protect
> that part of the code now with qemu_mutex_lock_iothread().
>
> Buglink: https://bugs.launchpad.net/qemu/+bug/1694998
> Signed-off-by: Thomas Huth <[hidden email]>

Applied to ppc-for-2.10.

> ---
>  target/ppc/excp_helper.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/target/ppc/excp_helper.c b/target/ppc/excp_helper.c
> index 9cb2123..3a9f086 100644
> --- a/target/ppc/excp_helper.c
> +++ b/target/ppc/excp_helper.c
> @@ -17,6 +17,7 @@
>   * License along with this library; if not, see <http://www.gnu.org/licenses/>.
>   */
>  #include "qemu/osdep.h"
> +#include "qemu/main-loop.h"
>  #include "cpu.h"
>  #include "exec/helper-proto.h"
>  #include "exec/exec-all.h"
> @@ -1132,6 +1133,7 @@ void helper_msgsnd(target_ulong rb)
>          return;
>      }
>  
> +    qemu_mutex_lock_iothread();
>      CPU_FOREACH(cs) {
>          PowerPCCPU *cpu = POWERPC_CPU(cs);
>          CPUPPCState *cenv = &cpu->env;
> @@ -1141,5 +1143,6 @@ void helper_msgsnd(target_ulong rb)
>              cpu_interrupt(cs, CPU_INTERRUPT_HARD);
>          }
>      }
> +    qemu_mutex_unlock_iothread();
>  }
>  #endif
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you.  NOT _the_ _other_
                                | _way_ _around_!
http://www.ozlabs.org/~dgibson

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Qemu-ppc] [PATCH] target/ppc/excp_helper: Take BQL before calling cpu_interrupt()

Nikunj A Dadhania
In reply to this post by Alex Bennée-2
Alex Bennée <[hidden email]> writes:

> Thomas Huth <[hidden email]> writes:
>
>> Since the introduction of MTTCG, using the msgsnd instruction
>> abort()s if being called without holding the BQL. So let's protect
>> that part of the code now with qemu_mutex_lock_iothread().
>>
>> Buglink: https://bugs.launchpad.net/qemu/+bug/1694998
>> Signed-off-by: Thomas Huth <[hidden email]>
>
> Reviewed-by: Alex Bennée <[hidden email]>
>
> p.s. I was checking the ppc code for other CPU_FOREACH patterns and I
> noticed the tlb_flush calls could probably use the tlb_flush_all_cpus
> API instead of manually looping themselves.

Will that be synchronous call? In PPC, we do lazy tlb flush, the tlb
flushes are batched until a synchronization point (for optimization).
The batching is achieved using a tlb_need_flush (global/local) and when
there is isync/ptesync or an exception, the actual flush is done. At
this point we need to make sure that the flush is synchronous.

> You should also double check the semantics to make sure none of them
> need to use the _synced variant and a cpu_exit if the flush needs to
> complete w.r.t the originating CPU.

Regards,
Nikunj


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Qemu-ppc] [PATCH] target/ppc/excp_helper: Take BQL before calling cpu_interrupt()

Alex Bennée-2

Nikunj A Dadhania <[hidden email]> writes:

> Alex Bennée <[hidden email]> writes:
>
>> Thomas Huth <[hidden email]> writes:
>>
>>> Since the introduction of MTTCG, using the msgsnd instruction
>>> abort()s if being called without holding the BQL. So let's protect
>>> that part of the code now with qemu_mutex_lock_iothread().
>>>
>>> Buglink: https://bugs.launchpad.net/qemu/+bug/1694998
>>> Signed-off-by: Thomas Huth <[hidden email]>
>>
>> Reviewed-by: Alex Bennée <[hidden email]>
>>
>> p.s. I was checking the ppc code for other CPU_FOREACH patterns and I
>> noticed the tlb_flush calls could probably use the tlb_flush_all_cpus
>> API instead of manually looping themselves.
>
> Will that be synchronous call? In PPC, we do lazy tlb flush, the tlb
> flushes are batched until a synchronization point (for optimization).

No by default the non-synced flushes will occur at the end of the
current executing block (cpu->exit_request is set and the work is done
when we exit the run-loop).

> The batching is achieved using a tlb_need_flush (global/local) and when
> there is isync/ptesync or an exception, the actual flush is done. At
> this point we need to make sure that the flush is synchronous.

If you want to ensure the flush is synchronous you need to call the
_all_cpus_synced variants and do a cpu_loop_exit in your helper. This
ensures that all the flushes queued up will be executed before execution
starts at the next PC of the calling thread.

>
>> You should also double check the semantics to make sure none of them
>> need to use the _synced variant and a cpu_exit if the flush needs to
>> complete w.r.t the originating CPU.
>
> Regards,
> Nikunj


--
Alex Bennée

Loading...