Hi,
Following this afternoons call I thought I'd summarise the state of the
various patch series and their relative dependencies. We re-stated the
aim should be to get what is up-streamable through the review process
and heading for merge so the delta for a full working MTTCG can be as
low as possible. There was some concern about the practicality of
submitting patches where the full benefit will not be seen until MTTCG
is finally merged.
On the patch submission note could I encourage posting public git trees
along with the patches for ease of review?
BQL lock breaking patches, Paolo/Jan
- required for working virt-io in MTTCG
- supersedes some of Fred's patches
- merged upstream as of -rc0
TCG async_safe_work, Fred
- http://git.greensocs.com/fkonrad/mttcg.git async_work_v3
- address@hidden
- split from earlier MTTCG patch series
- needed for cross-cpu sync mechanism for main series and slow-path
- candidate for upstreaming, but only MTTCG uses for now?
Slow-path for atomic instruction translation, Alvise
- address@hidden
- Needs re-basing to use TCG async_safe_work
- Earlier part of series (pre MTTCG) could be upstreamed as is
- Concern about performance impact in non-MTTCG scenarios
- Single CPU thread impact may be minimal with latest version, needs
benchmarking
- Also incomplete backend support, would BACKEND_HAS_LLSC_OPS be
acceptable to maintainers while support added by more knowledgable
backend people for non-x86/arm backends?
Multi-threaded TCG V6, Fred
- address@hidden:fkonrad/mttcg.git branch multi_tcg_v6
- address@hidden
- Needs re-basing on top of latest -rc (BQL breaking)
- Contains the rest of the MTTCG work (tb locking, tlb stuff etc)
- Currently target-arm only, other builds broken
As far as balancing the desire to get things upstreamed versus having a
stable base for testing I suggest we try an approach like this:
- select the current upstream -rc as the common base point
- create a branch from -rc with:
- stuff submitted for upstream (reviewed, not nacked)
- doesn't break any tree
- has minimal performance impact
Then both Fred and Alvise could base their trees of this point and we
aim to rebase onto a new branch each time the patches get merged into a
new upstream RC. The question then become how to deal with any
cross-dependencies between the slow-path and the main MTTCG branches?
I suspect the initial common branch point would just be
2.4.0-rc1+safe_async.
Does that sound workable?