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

[Frederic Konrad]

On 20/07/2015 19:41, alvise rigo wrote:
> 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
The RFC V3 you sent is based on MTTCG if I remember right.
That's why you introduced this rendez-vous right?

And the point was to use async_safe_work for this as I need it actually for
tb_flush and tb_invalidate (if we don't find any other solution for 
tb_invalidate).

So this is the cross-dependency which we are talking of.
But maybe and probably this is not needed with upstream as there is only 
one TCG
thread.

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