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-pbonz...@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
