Re: [Qemu-devel] MTTCG Tasks (kvmforum summary)

[Frederic Konrad <fred.konrad@greensocs.com>]

Hi Alex,

On 04/09/2015 09:49, Alex Bennée wrote:
> Hi,
>
> At KVM Forum I sat down with Paolo and Frederic and we came up with the
> current outstanding tasks on MTTCG. This is not comprehensive but
> hopefully covers the big areas. They are sorted in rough order we'd like
> to get them up-streamed.
>
> * linux-user patches (Paolo)
>
> Paolo has already grabbed a bunch of Fred's patch set where it makes
> sense on its own. They are up on the list and need review to expedite
> there way into the main tree now it is open for pull requests.
>
> See thread: 1439397664-70734-1-git-send-email-pbonzini@redhat.com
>
> * TLB_EXCL based LL/SC patches (Alvise)
>
> I think our consensus is these provide a good basis for the solution to
> modelling our atomics within TCG. I haven't had a chance to review
> Emilio's series yet which may approach this problem differently. I think
> the core patches with the generic backend support make a good basis to
> base development work on.
>
> We need to iterate and review the non-MTTCG variant of the patch set
> with a view to up-streaming soon.
>
> * Signal free qemu_cpu_kick (Paolo)
>
> I don't know much about this patch set but I assume this avoids the need
> to catch signals and longjmp about just to wake up?
>
> * RCU tb_flush (needs writing)
>
> The idea has been floated to introduce an RCU based translation buffer
> to flushes can be done lazily and the buffers dumped once all threads
> have stopped using them.
>
> I have been pondering if looking into having translation regions would
> be worth looking into so we can have translation buffers for contiguous
> series of pages. That way we don't have to throw away all translations
> on these big events. Currently every time we roll over the translation
> buffer we throw a bunch of perfectly good code away. This may or may not
> be orthogonal to using RCU?
I'm still not sure tb_flush needs so much effort.
tb_flush is happening very rarely just exiting everybody seems easier..

>
> * Memory barrier support (need RFC for discussion)
>
> I came to KVM forum with a back of the envelope idea we could implement
> one or two barrier ops (acquire/release?). Various suggestions of other
> types of memory behaviour have been suggested.
>
> I'll try to pull together an RFC patch with design outline for
> discussion. It would be nice to be able to demonstrate barrier failures
> in my test cases as well ;-)
>
> * longjmp in cpu_exec
>
> Paolo is fairly sure that if you take page faults while IRQs happening
> problems will occur with cpu->interrupt_request. Does it need to take
> the BQL?
>
> I'd like to see if we can get a torture test to stress this code
> although it will require IPI support in the unit tests.
>
> * tlb_flush and dmb behaviour (am I waiting for TLB flush?)
>
> I think this means we need explicit memory barriers to sync updates to
> the tlb.
>
> * tb_find_fast outside the lock
>
> Currently it is a big performance win as the tb_find_fast has a lot of
> contention with other threads. However there is concern it needs to be
> properly protected.
>
> * Additional review comments on the Fred's branch
>   - page->code_bitmap isn't protected by lock
>   - cpu_breakpoint_insert needs locks
Thoses one are OK, I didn't send all that yet.

>   - check gdbstub works
>
> * What to do about icount?
>
> What is the impact of multi-thread on icount? Do we need to disable it
> for MTTCG or can it be correct per-cpu? Can it be updated lock-step?
>
> We need some input from the guys that use icount the most.
>
> Cheers,
>
Also we might want to have everything in a branch. So rebasing the 
Atomics series
on eg: 2.4.0 + 2 Paolo's series so I can rebase MTTCG on it and pick the 
MTTCG
atomic parts can be usefull.

Thanks,
Fred