[Qemu-devel] Summary MTTCG related patch sets

[Qemu-devel] Summary MTTCG related patch sets

[Alex Bennée]

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
  - [1437144337-21442-1-git-send-email-fred.konrad@greensocs.com]
  - 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
  - [1436516626-8322-1-git-send-email-a.rigo@virtualopensystems.com]
  - 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
  - git@git.greensocs.com:fkonrad/mttcg.git branch multi_tcg_v6
  - [1435330053-18733-1-git-send-email-fred.konrad@greensocs.com]
  - 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?

-- 
Alex Bennée

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

[Mark Burton]

Huge thanks Alex, really good summary
Cheers
Mark.

> On 20 Jul 2015, at 18:17, Alex Bennée <alex.bennee@linaro.org> 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
>  - [1437144337-21442-1-git-send-email-fred.konrad@greensocs.com]
>  - 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
>  - [1436516626-8322-1-git-send-email-a.rigo@virtualopensystems.com]
>  - 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
>  - git@git.greensocs.com:fkonrad/mttcg.git branch multi_tcg_v6
>  - [1435330053-18733-1-git-send-email-fred.konrad@greensocs.com]
>  - 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?
> 
> -- 
> Alex Bennée


	 +44 (0)20 7100 3485 x 210
 +33 (0)5 33 52 01 77x 210

	+33 (0)603762104
	mark.burton

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 <alex.bennee@linaro.org> 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
>   - [1437144337-21442-1-git-send-email-fred.konrad@greensocs.com]
>   - 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
>   - [1436516626-8322-1-git-send-email-a.rigo@virtualopensystems.com]
>   - 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
>   - git@git.greensocs.com:fkonrad/mttcg.git branch multi_tcg_v6
>   - [1435330053-18733-1-git-send-email-fred.konrad@greensocs.com]
>   - 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

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

[Frederic Konrad]

On 20/07/2015 18:17, Alex Bennée 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
>    - [1437144337-21442-1-git-send-email-fred.konrad@greensocs.com]
>    - 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
>    - [1436516626-8322-1-git-send-email-a.rigo@virtualopensystems.com]
>    - 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
>    - git@git.greensocs.com:fkonrad/mttcg.git branch multi_tcg_v6
>    - [1435330053-18733-1-git-send-email-fred.konrad@greensocs.com]
>    - 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?
>
Yes it seems a good idea.
Which commit do you want to rebase on? Can you provide any hashtag?

Thanks,
Fred

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 <alex.bennee@linaro.org> 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
>>    - [1437144337-21442-1-git-send-email-fred.konrad@greensocs.com]
>>    - 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
>>    - [1436516626-8322-1-git-send-email-a.rigo@virtualopensystems.com]
>>    - 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
>>    - git@git.greensocs.com:fkonrad/mttcg.git branch multi_tcg_v6
>>    - [1435330053-18733-1-git-send-email-fred.konrad@greensocs.com]
>>    - 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

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

[alvise rigo]

On Mon, Jul 20, 2015 at 8:01 PM, Frederic Konrad
<fred.konrad@greensocs.com> wrote:
> 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 <alex.bennee@linaro.org>
>> 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
>>>    - [1437144337-21442-1-git-send-email-fred.konrad@greensocs.com]
>>>    - 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
>>>    - [1436516626-8322-1-git-send-email-a.rigo@virtualopensystems.com]
>>>    - 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
>>>    - git@git.greensocs.com:fkonrad/mttcg.git branch multi_tcg_v6
>>>    - [1435330053-18733-1-git-send-email-fred.konrad@greensocs.com]
>>>    - 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?

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.

Exactly. I've also managed to use the plain async_run_on_cpu for the
slow-path, so I don't really think there will be problems of
cross-dependencies.

Regards,
alvise

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

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

[Alex Bennée]

alvise rigo <a.rigo@virtualopensystems.com> writes:

> On Mon, Jul 20, 2015 at 8:01 PM, Frederic Konrad
> <fred.konrad@greensocs.com> wrote:
>> 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 <alex.bennee@linaro.org>
>>> 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
>>>>    - [1437144337-21442-1-git-send-email-fred.konrad@greensocs.com]
>>>>    - 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
>>>>    - [1436516626-8322-1-git-send-email-a.rigo@virtualopensystems.com]
>>>>    - 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
>>>>    - git@git.greensocs.com:fkonrad/mttcg.git branch multi_tcg_v6
>>>>    - [1435330053-18733-1-git-send-email-fred.konrad@greensocs.com]
>>>>    - 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?
>
> 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.
>
> Exactly. I've also managed to use the plain async_run_on_cpu for the
> slow-path, so I don't really think there will be problems of
> cross-dependencies.

Does that mean (performance permitting) any of the patch set can go
upstream before the main MTTCG patch set? Or is it intimately tied to
Fred's set for now? 

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

-- 
Alex Bennée

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

[alvise rigo]

On Wed, Jul 22, 2015 at 3:56 PM, Alex Bennée <alex.bennee@linaro.org> wrote:
>
> alvise rigo <a.rigo@virtualopensystems.com> writes:
>
>> On Mon, Jul 20, 2015 at 8:01 PM, Frederic Konrad
>> <fred.konrad@greensocs.com> wrote:
>>> 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 <alex.bennee@linaro.org>
>>>> 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
>>>>>    - [1437144337-21442-1-git-send-email-fred.konrad@greensocs.com]
>>>>>    - 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
>>>>>    - [1436516626-8322-1-git-send-email-a.rigo@virtualopensystems.com]
>>>>>    - 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
>>>>>    - git@git.greensocs.com:fkonrad/mttcg.git branch multi_tcg_v6
>>>>>    - [1435330053-18733-1-git-send-email-fred.konrad@greensocs.com]
>>>>>    - 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?
>>
>> 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.
>>
>> Exactly. I've also managed to use the plain async_run_on_cpu for the
>> slow-path, so I don't really think there will be problems of
>> cross-dependencies.
>
> Does that mean (performance permitting) any of the patch set can go
> upstream before the main MTTCG patch set?

Yes. A version of the patch series based on upstream QEMU (no
multithreading at all) does not require any of the patches introduced
by MTTCG.
On the contrary, a version made to work with MTTCG will have few
cross-dependencies.

Regards,
alvise

> Or is it intimately tied to
> Fred's set for now?
>
>>
>> Regards,
>> alvise
>>
>>>
>>> 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
>>>
>>>
>
> --
> Alex Bennée