On 14/08/2015 10:38, Frederic Konrad wrote:
>> Are you likely to push a v8 this week (or a temp branch?) with this and
>> any other obvious fixes? I appreciate Paolo has given you a not-so-small
>> pile of review comments as well so I wasn't looking for a complete new
>> patch set!
> here is some
On 12/08/2015 20:20, Alex Bennée wrote:
Frederic Konrad writes:
On 10/08/2015 17:27, fred.kon...@greensocs.com wrote:
From: KONRAD Frederic
This protects TBContext with tb_lock to make tb_* thread safe.
We can still have issue with tb_flush in case of multithread TCG:
An other CPU can
Frederic Konrad writes:
> On 10/08/2015 17:27, fred.kon...@greensocs.com wrote:
>> From: KONRAD Frederic
>>
>> This protects TBContext with tb_lock to make tb_* thread safe.
>>
>> We can still have issue with tb_flush in case of multithread TCG:
>>An other CPU can be executing code during a
> Are you likely to push a v8 this week (or a temp branch?) with this and
> any other obvious fixes? I appreciate Paolo has given you a not-so-small
> pile of review comments as well so I wasn't looking for a complete new
> patch set!
FWIW, reviews of the patches I posted a hour or two ago are we
On 10/08/2015 17:27, fred.kon...@greensocs.com wrote:
From: KONRAD Frederic
This protects TBContext with tb_lock to make tb_* thread safe.
We can still have issue with tb_flush in case of multithread TCG:
An other CPU can be executing code during a flush.
This can be fixed later by making
On 11/08/2015 11:21, Peter Maydell wrote:
> > > I think it's definitely not sufficient. Is user-mode multithread still
> > > working today?
> >
> > For some definition of "working", yes. It's not sufficient, but it's a
> > good start.
> >
> > The main problem with user-mode multithreading is tha
On 11 August 2015 at 09:34, Paolo Bonzini wrote:
>
>
> On 11/08/2015 08:46, Frederic Konrad wrote:
>>> I think you should start easy and reuse the existing tb_lock code in
>>> cpu-exec.c:
>>
>> I think it's definitely not sufficient. Is user-mode multithread still
>> working today?
>
> For some de
On 11/08/2015 08:46, Frederic Konrad wrote:
>> I think you should start easy and reuse the existing tb_lock code in
>> cpu-exec.c:
>
> I think it's definitely not sufficient. Is user-mode multithread still
> working today?
For some definition of "working", yes. It's not sufficient, but it's a
On 10/08/2015 20:39, Alex Bennée wrote:
> > ... ah, the lock is recursive!
> >
> > I think this can be avoided. Let's look at it next week.
>
> I take it your around on the Tuesday (Fred and I arrive Monday evening).
> Shall we pick a time or hunt for each other in the hacking room?
Yes, I wil
On 10/08/2015 18:36, Paolo Bonzini wrote:
On 10/08/2015 17:27, fred.kon...@greensocs.com wrote:
diff --git a/cpu-exec.c b/cpu-exec.c
index f3358a9..a012e9d 100644
--- a/cpu-exec.c
+++ b/cpu-exec.c
@@ -131,6 +131,8 @@ static void init_delay_params(SyncClocks *sc, const
CPUState *cpu)
void cpu
Paolo Bonzini writes:
> On 10/08/2015 18:36, Paolo Bonzini wrote:
>>> > diff --git a/target-arm/translate.c b/target-arm/translate.c
>>> > index 69ac18c..960c75e 100644
>>> > --- a/target-arm/translate.c
>>> > +++ b/target-arm/translate.c
>>> > @@ -11166,6 +11166,8 @@ static inline void
>>> > g
On 10/08/2015 18:36, Paolo Bonzini wrote:
>> > diff --git a/target-arm/translate.c b/target-arm/translate.c
>> > index 69ac18c..960c75e 100644
>> > --- a/target-arm/translate.c
>> > +++ b/target-arm/translate.c
>> > @@ -11166,6 +11166,8 @@ static inline void
>> > gen_intermediate_code_internal(A
On 10/08/2015 17:27, fred.kon...@greensocs.com wrote:
> diff --git a/cpu-exec.c b/cpu-exec.c
> index f3358a9..a012e9d 100644
> --- a/cpu-exec.c
> +++ b/cpu-exec.c
> @@ -131,6 +131,8 @@ static void init_delay_params(SyncClocks *sc, const
> CPUState *cpu)
> void cpu_loop_exit(CPUState *cpu)
> {
From: KONRAD Frederic
This protects TBContext with tb_lock to make tb_* thread safe.
We can still have issue with tb_flush in case of multithread TCG:
An other CPU can be executing code during a flush.
This can be fixed later by making all other TCG thread exiting before calling
tb_flush().
14 matches
Mail list logo
