Re: [Qemu-devel] Summary MTTCG related patch sets

[alvise rigo]

Hi Alex,

Thank you for this summary.
Some comments below.

On Mon, Jul 20, 2015 at 6:17 PM, Alex Bennée <address@hidden> wrote:
>
> 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

I will create a branch for upstreaming (pre MTTCG) and another one
based on MTTCG.

>   - 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?

>From my side I will take care of rebasing my patch series on the
latest MTTCG branch as often as possible. Up to now, there are not so
many cross-dependencies, so I don't see it as a big issue. Is this a
workable solution?

Thank you,
alvise

>
>
> I suspect the initial common branch point would just be
> 2.4.0-rc1+safe_async.
>
> Does that sound workable?
>
> --
> Alex Bennée