[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Frederic Konrad
Subject: Re: [Qemu-devel] Summary MTTCG related patch sets
Date: Mon, 20 Jul 2015 20:01:16 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0

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:

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


I suspect the initial common branch point would just be

Does that sound workable?

Alex Bennée

reply via email to

[Prev in Thread] Current Thread [Next in Thread]