Hi Paolo,
On Mon, Mar 7, 2016 at 10:18 PM, Paolo Bonzini wrote:
>
>
> On 04/03/2016 15:28, alvise rigo wrote:
>> A small update on this. I have a working implementation of the "halted
>> state" mechanism for waiting all the pending flushes to be completed.
>> However, the way I'm going back to th
On 04/03/2016 15:28, alvise rigo wrote:
> A small update on this. I have a working implementation of the "halted
> state" mechanism for waiting all the pending flushes to be completed.
> However, the way I'm going back to the cpus.c loop (the while(1) in
> qemu_tcg_cpu_thread_fn) is a bit convolu
alvise rigo writes:
> A small update on this. I have a working implementation of the "halted
> state" mechanism for waiting all the pending flushes to be completed.
> However, the way I'm going back to the cpus.c loop (the while(1) in
> qemu_tcg_cpu_thread_fn) is a bit convoluted. In the case of
A small update on this. I have a working implementation of the "halted
state" mechanism for waiting all the pending flushes to be completed.
However, the way I'm going back to the cpus.c loop (the while(1) in
qemu_tcg_cpu_thread_fn) is a bit convoluted. In the case of the TLB ops
that always end th
I see the risk. I will come back with something and let you know.
Thank you,
alvise
On Mon, Feb 29, 2016 at 3:06 PM, Paolo Bonzini wrote:
>
>
> On 29/02/2016 15:02, alvise rigo wrote:
>> > Yeah, that's the other approach -- really split the things that can
>> > be async and do real "wait for com
On 29/02/2016 15:02, alvise rigo wrote:
> > Yeah, that's the other approach -- really split the things that can
> > be async and do real "wait for completion" at points which must
> > synchronize. (Needs a little care since DMB is not the only such point.)
> > An initial implementation that does
On Mon, Feb 29, 2016 at 2:55 PM, Peter Maydell wrote:
> On 29 February 2016 at 13:50, Paolo Bonzini wrote:
>>
>>
>> On 29/02/2016 14:21, Peter Maydell wrote:
>>> On 29 February 2016 at 13:16, Alvise Rigo
>>> wrote:
> As in the case of tlb_flush(), also tlb_flush_by_mmuidx has to query the
On 29 February 2016 at 13:50, Paolo Bonzini wrote:
>
>
> On 29/02/2016 14:21, Peter Maydell wrote:
>> On 29 February 2016 at 13:16, Alvise Rigo
>> wrote:
>>> > As in the case of tlb_flush(), also tlb_flush_by_mmuidx has to query the
>>> > TLB flush if it targets another VCPU. To accomplish this,
On 29/02/2016 14:21, Peter Maydell wrote:
> On 29 February 2016 at 13:16, Alvise Rigo
> wrote:
>> > As in the case of tlb_flush(), also tlb_flush_by_mmuidx has to query the
>> > TLB flush if it targets another VCPU. To accomplish this, a new async
>> > work has been added, together with a new T
On 29 February 2016 at 13:16, Alvise Rigo wrote:
> As in the case of tlb_flush(), also tlb_flush_by_mmuidx has to query the
> TLB flush if it targets another VCPU. To accomplish this, a new async
> work has been added, together with a new TLBFlushByMMUIdxParams. A
> bitmap is used to track the MMU
As in the case of tlb_flush(), also tlb_flush_by_mmuidx has to query the
TLB flush if it targets another VCPU. To accomplish this, a new async
work has been added, together with a new TLBFlushByMMUIdxParams. A
bitmap is used to track the MMU indexes to flush.
This patch applies to the multi_tcg_v8
11 matches
Mail list logo
