On Fri, Jun 26, 2015 at 08:06:55AM +0100, Alex Bennée wrote:
>
> Andrew Jones writes:
>
> > On Wed, Jun 24, 2015 at 08:12:52PM +0100, Peter Maydell wrote:
> >> On 24 June 2015 at 18:18, Alex Bennée wrote:
> >> >
> >> > Paolo Bonzini writes:
> >> >
> >> >> On 24/06/2015 17:34, Alex Bennée wrote
Andrew Jones writes:
> On Wed, Jun 24, 2015 at 08:12:52PM +0100, Peter Maydell wrote:
>> On 24 June 2015 at 18:18, Alex Bennée wrote:
>> >
>> > Paolo Bonzini writes:
>> >
>> >> On 24/06/2015 17:34, Alex Bennée wrote:
>> >>> Testing with Alexander's bare metal syncronisation tests fails in MTTC
On Wed, Jun 24, 2015 at 08:12:52PM +0100, Peter Maydell wrote:
> On 24 June 2015 at 18:18, Alex Bennée wrote:
> >
> > Paolo Bonzini writes:
> >
> >> On 24/06/2015 17:34, Alex Bennée wrote:
> >>> Testing with Alexander's bare metal syncronisation tests fails in MTTCG
> >>> leaving one CPU spinning
On 25/06/2015 01:55, Alexander Spyridakis wrote:
On 24 June 2015 at 17:34, Alex Bennée wrote:
Testing with Alexander's bare metal syncronisation tests fails in MTTCG
leaving one CPU spinning forever waiting for the second CPU to wake up.
We simply need to poke the halt_cond once we have process
Alexander Spyridakis writes:
> On 24 June 2015 at 17:34, Alex Bennée wrote:
>> Testing with Alexander's bare metal syncronisation tests fails in MTTCG
>> leaving one CPU spinning forever waiting for the second CPU to wake up.
>> We simply need to poke the halt_cond once we have processed the PS
On 24 June 2015 at 17:34, Alex Bennée wrote:
> Testing with Alexander's bare metal syncronisation tests fails in MTTCG
> leaving one CPU spinning forever waiting for the second CPU to wake up.
> We simply need to poke the halt_cond once we have processed the PSCI
> power on call.
Thanks Alex. Wor
On 24 June 2015 at 18:18, Alex Bennée wrote:
>
> Paolo Bonzini writes:
>
>> On 24/06/2015 17:34, Alex Bennée wrote:
>>> Testing with Alexander's bare metal syncronisation tests fails in MTTCG
>>> leaving one CPU spinning forever waiting for the second CPU to wake up.
>>> We simply need to poke th
Paolo Bonzini writes:
> On 24/06/2015 19:18, Alex Bennée wrote:
>> @@ -196,6 +196,8 @@ void arm_handle_psci_call(ARMCPU *cpu)
>> }
>> target_cpu_class->set_pc(target_cpu_state, entry);
>>
>> +qemu_cond_signal(target_cpu_state->halt_cond);
>>>
On 24/06/2015 19:18, Alex Bennée wrote:
>>> >> @@ -196,6 +196,8 @@ void arm_handle_psci_call(ARMCPU *cpu)
>>> >> }
>>> >> target_cpu_class->set_pc(target_cpu_state, entry);
>>> >>
>>> >> +qemu_cond_signal(target_cpu_state->halt_cond);
>> >
>> > That's called qemu_cpu_k
Paolo Bonzini writes:
> On 24/06/2015 17:34, Alex Bennée wrote:
>> Testing with Alexander's bare metal syncronisation tests fails in MTTCG
>> leaving one CPU spinning forever waiting for the second CPU to wake up.
>> We simply need to poke the halt_cond once we have processed the PSCI
>> power o
On 24/06/2015 17:34, Alex Bennée wrote:
> Testing with Alexander's bare metal syncronisation tests fails in MTTCG
> leaving one CPU spinning forever waiting for the second CPU to wake up.
> We simply need to poke the halt_cond once we have processed the PSCI
> power on call.
>
> Tested-by: Alex
Testing with Alexander's bare metal syncronisation tests fails in MTTCG
leaving one CPU spinning forever waiting for the second CPU to wake up.
We simply need to poke the halt_cond once we have processed the PSCI
power on call.
Tested-by: Alex Bennée
CC: Alexander Spyridakis
---
TODO
- exactl
12 matches
Mail list logo
