On 09/19/2016 01:25 PM, David Hildenbrand wrote:
[...]
>>
>> We only do the slow path things in QEMU. Maybe we could just have one lock
>> that
>> we trylock and return a condition code of 2 (busy) if we fail. That seems
>> the
>> most simple solution while still being architecturally correct. S
> On 09/15/2016 09:21 PM, David Hildenbrand wrote:
> >> On 09/12/2016 08:03 PM, Paolo Bonzini wrote:
> >>>
> >>>
> >>> On 12/09/2016 19:37, Christian Borntraeger wrote:
> On 09/12/2016 06:44 PM, Paolo Bonzini wrote:
> > I think that two CPUs doing reciprocal SIGPs could in princi
On 09/15/2016 09:21 PM, David Hildenbrand wrote:
>> On 09/12/2016 08:03 PM, Paolo Bonzini wrote:
>>>
>>>
>>> On 12/09/2016 19:37, Christian Borntraeger wrote:
On 09/12/2016 06:44 PM, Paolo Bonzini wrote:
> I think that two CPUs doing reciprocal SIGPs could in principle end up
> wai
On 15/09/2016 21:21, David Hildenbrand wrote:
> Smells like having to provide a lock per CPU. Trylock that lock, if that's not
> possible, cc=busy. SIGP SET ARCHITECTURE has to lock all CPUs.
Makes sense. On the other hand:
- you have to trylock both the source and the destination, I think.
-
> On 09/12/2016 08:03 PM, Paolo Bonzini wrote:
> >
> >
> > On 12/09/2016 19:37, Christian Borntraeger wrote:
> >> On 09/12/2016 06:44 PM, Paolo Bonzini wrote:
> >>> I think that two CPUs doing reciprocal SIGPs could in principle end up
> >>> waiting on each other to complete their run_on_cpu.
On 09/12/2016 08:03 PM, Paolo Bonzini wrote:
>
>
> On 12/09/2016 19:37, Christian Borntraeger wrote:
>> On 09/12/2016 06:44 PM, Paolo Bonzini wrote:
>>> I think that two CPUs doing reciprocal SIGPs could in principle end up
>>> waiting on each other to complete their run_on_cpu. If the SIGP has
On 12/09/2016 19:37, Christian Borntraeger wrote:
> On 09/12/2016 06:44 PM, Paolo Bonzini wrote:
> > I think that two CPUs doing reciprocal SIGPs could in principle end up
> > waiting on each other to complete their run_on_cpu. If the SIGP has to
> > be synchronous the fix is not trivial (you'd
On 09/12/2016 06:44 PM, Paolo Bonzini wrote:
> I think that two CPUs doing reciprocal SIGPs could in principle end up
> waiting on each other to complete their run_on_cpu. If the SIGP has to
> be synchronous the fix is not trivial (you'd have to put the CPU in a
> state similar to cpu->halted = 1)
I think that two CPUs doing reciprocal SIGPs could in principle end up
waiting on each other to complete their run_on_cpu. If the SIGP has to
be synchronous the fix is not trivial (you'd have to put the CPU in a
state similar to cpu->halted = 1), otherwise it's enough to replace
run_on_cpu with as
