Re: [Qemu-devel] MTTCG sync-up call today?

Re: [Qemu-devel] MTTCG sync-up call today?

[Alex Bennée]

KONRAD Frederic <fred.konrad@greensocs.com> writes:

> Le 04/01/2016 12:43, Alex Bennée a écrit :
>> Hi,
>>
>> Firstly Happy New Year, I hope everyone is refreshed and rested after
>> the holiday season ;-)
>>
>> My calender has reminded me there is a potential call today. Is it worth
>> having or will the status be pretty much as we left it last year thanks
>> to holidays?
>>
>> For my part I started going through Alvise's patch series last year
>> before the holiday started. After I've spun up back to speed today I
>> intend to finish that review.
>>
>> The current blocker on progress is the re-spin/re-base of Fred's patches
>> I think. I had a bit of a look last year and I think we identified at
>> least one major problem with the exit_request stuff which Paolo reminded
>> me had been mentioned before.
>>
>> Fred if you are struggling to find time I can pick up the current WIP
>> branch and see if I can get it into shape for submission?
>>
>> Cheers,
>>
>> --
>> Alex Bennée
>
> Hi,
>
> Sorry for the late answer, I find some time to take a look at it.
>
> Seems you were right I fixed the exit issue and it seems it was one of
> the problem.
> I think we must double check how we use cpu->exit_request as Paolo
> removed SIG_IPI to exit the CPU.
>
> I found one additional issue and it seems booting well right now.

The other thing that needs cleaning up is the tcg_current_cpu and
current_cpu. I suspect the former should go and the restrictions on the
later be loosend so the TLS current_cpu is available to deferred tasks.

The thing I'm currently looking at is what happens when something like a
virtio completes in a non-CPU thread.

>
> Tomorrow I'll test that a little more, try to clean that up and
> hopefully send you a link to the repo.
>
> Thanks,
> Fred


--
Alex Bennée

Re: [Qemu-devel] MTTCG sync-up call today?

[Paolo Bonzini]

On 12/01/2016 16:11, Alex Bennée wrote:
> > Sorry for the late answer, I find some time to take a look at it.
> >
> > Seems you were right I fixed the exit issue and it seems it was one of
> > the problem.
> > I think we must double check how we use cpu->exit_request as Paolo
> > removed SIG_IPI to exit the CPU.
> >
> > I found one additional issue and it seems booting well right now.
>
> The other thing that needs cleaning up is the tcg_current_cpu and
> current_cpu. I suspect the former should go and the restrictions on the
> later be loosend so the TLS current_cpu is available to deferred tasks.

Yes, you can make TLS current_cpu always non-NULL for multi-threaded TCG.

tcg_current_cpu definitely should go, it doesn't make sense if you have
multiple threads.

> The thing I'm currently looking at is what happens when something like a
> virtio completes in a non-CPU thread.

It should just work.  It will cause a cpu_interrupt under the BQL, and
that sets cpu->interrupt_request.  The code that modifies
cpu->interrupt_request in the VCPU thread also runs under the BQL.

Paolo

Re: [Qemu-devel] MTTCG sync-up call today?

[Alex Bennée]

Paolo Bonzini <pbonzini@redhat.com> writes:

> On 12/01/2016 16:11, Alex Bennée wrote:
>> > Sorry for the late answer, I find some time to take a look at it.
>> >
>> > Seems you were right I fixed the exit issue and it seems it was one of
>> > the problem.
>> > I think we must double check how we use cpu->exit_request as Paolo
>> > removed SIG_IPI to exit the CPU.
>> >
>> > I found one additional issue and it seems booting well right now.
>>
>> The other thing that needs cleaning up is the tcg_current_cpu and
>> current_cpu. I suspect the former should go and the restrictions on the
>> later be loosend so the TLS current_cpu is available to deferred tasks.
>
> Yes, you can make TLS current_cpu always non-NULL for multi-threaded TCG.
>
> tcg_current_cpu definitely should go, it doesn't make sense if you have
> multiple threads.
>
>> The thing I'm currently looking at is what happens when something like a
>> virtio completes in a non-CPU thread.
>
> It should just work.  It will cause a cpu_interrupt under the BQL, and
> that sets cpu->interrupt_request.  The code that modifies
> cpu->interrupt_request in the VCPU thread also runs under the BQL.

Hmm I'm seeing a virtio co-routine kick of an unmap:

qemu-system-arm: /home/alex/lsrc/qemu/qemu.git/translate-all.c:1303: tb_invalidate_phys_range: Assertion `have_tb_lock' failed.

Program received signal SIGABRT, Aborted.
0x00007ffff0ae9cc9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56	../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  0x00007ffff0ae9cc9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x00007ffff0aed0d8 in __GI_abort () at abort.c:89
#2  0x00007ffff0ae2b86 in __assert_fail_base (fmt=0x7ffff0c33830 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n",
    assertion=assertion@entry=0x555555a89665 "have_tb_lock", file=file@entry=0x555555a894f0 "/home/alex/lsrc/qemu/qemu.git/translate-all.c", line=line@entry=1303,
    function=function@entry=0x555555a897f0 <__PRETTY_FUNCTION__.33460> "tb_invalidate_phys_range") at assert.c:92
#3  0x00007ffff0ae2c32 in __GI___assert_fail (assertion=assertion@entry=0x555555a89665 "have_tb_lock",
    file=file@entry=0x555555a894f0 "/home/alex/lsrc/qemu/qemu.git/translate-all.c", line=line@entry=1303,
    function=function@entry=0x555555a897f0 <__PRETTY_FUNCTION__.33460> "tb_invalidate_phys_range") at assert.c:101
#4  0x00005555556e5b06 in tb_invalidate_phys_range (start=start@entry=0, end=end@entry=4096) at /home/alex/lsrc/qemu/qemu.git/translate-all.c:1303
#5  0x00005555556dbe42 in invalidate_and_set_dirty (mr=mr@entry=0x555556571800, addr=0, length=length@entry=4096) at /home/alex/lsrc/qemu/qemu.git/exec.c:2420
#6  0x00005555556e1890 in address_space_unmap (as=as@entry=0x555555ff7000 <address_space_memory>, buffer=<optimised out>, len=<optimised out>,
    is_write=is_write@entry=1, access_len=access_len@entry=4096) at /home/alex/lsrc/qemu/qemu.git/exec.c:2933
#7  0x00005555556e19bf in cpu_physical_memory_unmap (buffer=<optimised out>, len=<optimised out>, is_write=is_write@entry=1, access_len=access_len@entry=4096)
    at /home/alex/lsrc/qemu/qemu.git/exec.c:2962
#8  0x000055555578219c in virtqueue_unmap_sg (elem=elem@entry=0x7ffe782c7cf0, len=len@entry=4097, vq=0x555556e6f020)
    at /home/alex/lsrc/qemu/qemu.git/hw/virtio/virtio.c:257
#9  0x0000555555782ac0 in virtqueue_fill (vq=vq@entry=0x555556e6f020, elem=elem@entry=0x7ffe782c7cf0, len=4097, idx=idx@entry=0)
    at /home/alex/lsrc/qemu/qemu.git/hw/virtio/virtio.c:282
#10 0x0000555555782ccf in virtqueue_push (vq=0x555556e6f020, elem=elem@entry=0x7ffe782c7cf0, len=<optimised out>)
    at /home/alex/lsrc/qemu/qemu.git/hw/virtio/virtio.c:308
#11 0x000055555573451a in virtio_blk_complete_request (req=0x7ffe782c7ce0, status=<optimised out>) at /home/alex/lsrc/qemu/qemu.git/hw/block/virtio-blk.c:58
#12 0x0000555555734a13 in virtio_blk_req_complete (status=0 '\000', req=0x7ffe782c7ce0) at /home/alex/lsrc/qemu/qemu.git/hw/block/virtio-blk.c:64
#13 virtio_blk_rw_complete (opaque=<optimised out>, ret=0) at /home/alex/lsrc/qemu/qemu.git/hw/block/virtio-blk.c:122
---Type <return> to continue, or q <return> to quit---
#14 0x0000555555a2d822 in bdrv_co_complete (acb=0x7ffe780189c0) at block/io.c:2122
#15 0x0000555555a87a7a in coroutine_trampoline (i0=<optimised out>, i1=<optimised out>) at util/coroutine-ucontext.c:80
#16 0x00007ffff0afc8b0 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#17 0x00007fff8f5aa6e0 in ?? ()
#18 0x0000000000000000 in ?? ()

I guess the tb_lock could just be grabbed but there is stuff in that
path that assumes current_cpu is valid so I thought the thing to do was
defer the operation until a "real" vCPU can deal with it.



>
> Paolo


--
Alex Bennée

Re: [Qemu-devel] MTTCG sync-up call today?

[Paolo Bonzini]

On 12/01/2016 17:13, Alex Bennée wrote:
> #4  0x00005555556e5b06 in tb_invalidate_phys_range (start=start@entry=0, end=end@entry=4096) at /home/alex/lsrc/qemu/qemu.git/translate-all.c:1303
> #5  0x00005555556dbe42 in invalidate_and_set_dirty (mr=mr@entry=0x555556571800, addr=0, length=length@entry=4096) at /home/alex/lsrc/qemu/qemu.git/exec.c:2420
> #6  0x00005555556e1890 in address_space_unmap (as=as@entry=0x555555ff7000 <address_space_memory>, buffer=<optimised out>, len=<optimised out>,
>     is_write=is_write@entry=1, access_len=access_len@entry=4096) at /home/alex/lsrc/qemu/qemu.git/exec.c:2933
> #7  0x00005555556e19bf in cpu_physical_memory_unmap (buffer=<optimised out>, len=<optimised out>, is_write=is_write@entry=1, access_len=access_len@entry=4096)
>     at /home/alex/lsrc/qemu/qemu.git/exec.c:2962
> #8  0x000055555578219c in virtqueue_unmap_sg (elem=elem@entry=0x7ffe782c7cf0, len=len@entry=4097, vq=0x555556e6f020)
>     at /home/alex/lsrc/qemu/qemu.git/hw/virtio/virtio.c:257
> #9  0x0000555555782ac0 in virtqueue_fill (vq=vq@entry=0x555556e6f020, elem=elem@entry=0x7ffe782c7cf0, len=4097, idx=idx@entry=0)
>     at /home/alex/lsrc/qemu/qemu.git/hw/virtio/virtio.c:282
> #10 0x0000555555782ccf in virtqueue_push (vq=0x555556e6f020, elem=elem@entry=0x7ffe782c7cf0, len=<optimised out>)
>     at /home/alex/lsrc/qemu/qemu.git/hw/virtio/virtio.c:308
> #11 0x000055555573451a in virtio_blk_complete_request (req=0x7ffe782c7ce0, status=<optimised out>) at /home/alex/lsrc/qemu/qemu.git/hw/block/virtio-blk.c:58
> #12 0x0000555555734a13 in virtio_blk_req_complete (status=0 '\000', req=0x7ffe782c7ce0) at /home/alex/lsrc/qemu/qemu.git/hw/block/virtio-blk.c:64
> #13 virtio_blk_rw_complete (opaque=<optimised out>, ret=0) at /home/alex/lsrc/qemu/qemu.git/hw/block/virtio-blk.c:122
> ---Type <return> to continue, or q <return> to quit---
> #14 0x0000555555a2d822 in bdrv_co_complete (acb=0x7ffe780189c0) at block/io.c:2122
> #15 0x0000555555a87a7a in coroutine_trampoline (i0=<optimised out>, i1=<optimised out>) at util/coroutine-ucontext.c:80
> #16 0x00007ffff0afc8b0 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
> #17 0x00007fff8f5aa6e0 in ?? ()
> #18 0x0000000000000000 in ?? ()
> 
> I guess the tb_lock could just be grabbed but there is stuff in that
> path that assumes current_cpu is valid so I thought the thing to do was
> defer the operation until a "real" vCPU can deal with it.

I need to look at the branch...  The latest version I have here does
not require tb_lock taken in tb_invalidate_phys_range.

/*
 * Invalidate all TBs which intersect with the target physical address range
 * [start;end[. NOTE: start and end may refer to *different* physical pages.
 * 'is_cpu_write_access' should be true if called from a real cpu write
 * access: the virtual CPU will exit the current TB if code is modified inside
 * this TB.
 *
 * Called with mmap_lock held for user-mode emulation
 */
void tb_invalidate_phys_range(tb_page_addr_t start, tb_page_addr_t end)
{
    while (start < end) {
        tb_invalidate_phys_page_range(start, end, 0);
        start &= TARGET_PAGE_MASK;
        start += TARGET_PAGE_SIZE;
    }
}

/*
 * Invalidate all TBs which intersect with the target physical address range
 * [start;end[. NOTE: start and end must refer to the *same* physical page.
 * 'is_cpu_write_access' should be true if called from a real cpu write
 * access: the virtual CPU will exit the current TB if code is modified inside
 * this TB.
 *
 * Called with mmap_lock held for user-mode emulation
 * If called from generated code, iothread mutex must not be held.
 */
void tb_invalidate_phys_page_range(tb_page_addr_t start, tb_page_addr_t end,
                                   int is_cpu_write_access)


Paolo

Re: [Qemu-devel] MTTCG sync-up call today?

[Alex Bennée]

Paolo Bonzini <pbonzini@redhat.com> writes:

> On 12/01/2016 17:13, Alex Bennée wrote:
>> #4  0x00005555556e5b06 in tb_invalidate_phys_range (start=start@entry=0, end=end@entry=4096) at /home/alex/lsrc/qemu/qemu.git/translate-all.c:1303
>> #5  0x00005555556dbe42 in invalidate_and_set_dirty (mr=mr@entry=0x555556571800, addr=0, length=length@entry=4096) at /home/alex/lsrc/qemu/qemu.git/exec.c:2420
>> #6  0x00005555556e1890 in address_space_unmap (as=as@entry=0x555555ff7000 <address_space_memory>, buffer=<optimised out>, len=<optimised out>,
>>     is_write=is_write@entry=1, access_len=access_len@entry=4096) at /home/alex/lsrc/qemu/qemu.git/exec.c:2933
>> #7  0x00005555556e19bf in cpu_physical_memory_unmap (buffer=<optimised out>, len=<optimised out>, is_write=is_write@entry=1, access_len=access_len@entry=4096)
>>     at /home/alex/lsrc/qemu/qemu.git/exec.c:2962
>> #8  0x000055555578219c in virtqueue_unmap_sg (elem=elem@entry=0x7ffe782c7cf0, len=len@entry=4097, vq=0x555556e6f020)
>>     at /home/alex/lsrc/qemu/qemu.git/hw/virtio/virtio.c:257
>> #9  0x0000555555782ac0 in virtqueue_fill (vq=vq@entry=0x555556e6f020, elem=elem@entry=0x7ffe782c7cf0, len=4097, idx=idx@entry=0)
>>     at /home/alex/lsrc/qemu/qemu.git/hw/virtio/virtio.c:282
>> #10 0x0000555555782ccf in virtqueue_push (vq=0x555556e6f020, elem=elem@entry=0x7ffe782c7cf0, len=<optimised out>)
>>     at /home/alex/lsrc/qemu/qemu.git/hw/virtio/virtio.c:308
>> #11 0x000055555573451a in virtio_blk_complete_request (req=0x7ffe782c7ce0, status=<optimised out>) at /home/alex/lsrc/qemu/qemu.git/hw/block/virtio-blk.c:58
>> #12 0x0000555555734a13 in virtio_blk_req_complete (status=0 '\000', req=0x7ffe782c7ce0) at /home/alex/lsrc/qemu/qemu.git/hw/block/virtio-blk.c:64
>> #13 virtio_blk_rw_complete (opaque=<optimised out>, ret=0) at /home/alex/lsrc/qemu/qemu.git/hw/block/virtio-blk.c:122
>> ---Type <return> to continue, or q <return> to quit---
>> #14 0x0000555555a2d822 in bdrv_co_complete (acb=0x7ffe780189c0) at block/io.c:2122
>> #15 0x0000555555a87a7a in coroutine_trampoline (i0=<optimised out>, i1=<optimised out>) at util/coroutine-ucontext.c:80
>> #16 0x00007ffff0afc8b0 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
>> #17 0x00007fff8f5aa6e0 in ?? ()
>> #18 0x0000000000000000 in ?? ()
>>
>> I guess the tb_lock could just be grabbed but there is stuff in that
>> path that assumes current_cpu is valid so I thought the thing to do was
>> defer the operation until a "real" vCPU can deal with it.
>
> I need to look at the branch...  The latest version I have here does
> not require tb_lock taken in tb_invalidate_phys_range.

The tb_locks asserts where added in Fred's branch which makes sense as
we are going to mess with the translation block cache. Looking more
closely at tb_invalidate_phys_page_range I see it jumps through some
hoops when cpu == current_cpu == NULL.


>
> /*
>  * Invalidate all TBs which intersect with the target physical address range
>  * [start;end[. NOTE: start and end may refer to *different* physical pages.
>  * 'is_cpu_write_access' should be true if called from a real cpu write
>  * access: the virtual CPU will exit the current TB if code is modified inside
>  * this TB.
>  *
>  * Called with mmap_lock held for user-mode emulation
>  */
> void tb_invalidate_phys_range(tb_page_addr_t start, tb_page_addr_t end)
> {
>     while (start < end) {
>         tb_invalidate_phys_page_range(start, end, 0);
>         start &= TARGET_PAGE_MASK;
>         start += TARGET_PAGE_SIZE;
>     }
> }
>
> /*
>  * Invalidate all TBs which intersect with the target physical address range
>  * [start;end[. NOTE: start and end must refer to the *same* physical page.
>  * 'is_cpu_write_access' should be true if called from a real cpu write
>  * access: the virtual CPU will exit the current TB if code is modified inside
>  * this TB.
>  *
>  * Called with mmap_lock held for user-mode emulation
>  * If called from generated code, iothread mutex must not be held.
>  */
> void tb_invalidate_phys_page_range(tb_page_addr_t start, tb_page_addr_t end,
>                                    int is_cpu_write_access)
>
>
> Paolo


--
Alex Bennée

Re: [Qemu-devel] MTTCG sync-up call today?

[Paolo Bonzini]

On 12/01/2016 17:32, Alex Bennée wrote:
>> I need to look at the branch...  The latest version I have here does
>> not require tb_lock taken in tb_invalidate_phys_range.
> 
> The tb_locks asserts where added in Fred's branch which makes sense as
> we are going to mess with the translation block cache. Looking more
> closely at tb_invalidate_phys_page_range I see it jumps through some
> hoops when cpu == current_cpu == NULL.

Does tb_invalidate_phys_page_range not take tb_lock itself?

Paolo

Re: [Qemu-devel] MTTCG sync-up call today?

[Alex Bennée]

Paolo Bonzini <pbonzini@redhat.com> writes:

> On 12/01/2016 17:32, Alex Bennée wrote:
>>> I need to look at the branch...  The latest version I have here does
>>> not require tb_lock taken in tb_invalidate_phys_range.
>>
>> The tb_locks asserts where added in Fred's branch which makes sense as
>> we are going to mess with the translation block cache. Looking more
>> closely at tb_invalidate_phys_page_range I see it jumps through some
>> hoops when cpu == current_cpu == NULL.
>
> Does tb_invalidate_phys_page_range not take tb_lock itself?

You are right, I missed that when looking at the original code. I think
Fred was trying to push some of the locks up in his WIP branch causing
these problems.

I'll wait until his more complete branch is out.

>
> Paolo


--
Alex Bennée

Re: [Qemu-devel] MTTCG sync-up call today?

[Paolo Bonzini]

On 12/01/2016 18:05, Alex Bennée wrote:
>> > Does tb_invalidate_phys_page_range not take tb_lock itself?
> You are right, I missed that when looking at the original code. I think
> Fred was trying to push some of the locks up in his WIP branch causing
> these problems.

As far as I can see, that's unnecessary.  Please keep the patches as
small as possible and make things correct first.  Otherwise we keep
running in circles.

Paolo

Re: [Qemu-devel] MTTCG sync-up call today?

[Paolo Bonzini]

On 12/01/2016 18:05, Alex Bennée wrote:
>> > Does tb_invalidate_phys_page_range not take tb_lock itself?
> You are right, I missed that when looking at the original code. I think
> Fred was trying to push some of the locks up in his WIP branch causing
> these problems.

As far as I can see, that's unnecessary.  Please keep the patches as
small as possible and make things correct first.  Otherwise we keep
running in circles.

Paolo

Re: [Qemu-devel] MTTCG Sync-up call today?

[Alex Bennée]

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

> Not from my side.
> Hope to have some news by the end of the week.

Looking forward to it.

For my part the next iterations are in progress but I have nothing to
discuss today.

Sounds like we should wait until next time.

>
> Regards,
> alvise
>
> On Mon, May 9, 2016 at 1:56 PM, Alex Bennée <alex.bennee@linaro.org> wrote:
>
>>
>> Hi,
>>
>> Do we have anything we want to discuss today?
>>
>> --
>> Alex Bennée
>>


--
Alex Bennée

Re: [Qemu-devel] MTTCG Sync-up call today?

[alvise rigo]

Not from my side.
Hope to have some news by the end of the week.

Regards,
alvise

On Mon, May 9, 2016 at 1:56 PM, Alex Bennée <alex.bennee@linaro.org> wrote:

>
> Hi,
>
> Do we have anything we want to discuss today?
>
> --
> Alex Bennée
>

Re: [Qemu-devel] MTTCG Sync-up call today?

[KONRAD Frederic]

Hi Alex,

I can't do the call today, sorry.

Thanks,
Fred

Le 09/05/2016 13:56, Alex Bennée a écrit :
>
> Hi,
>
> Do we have anything we want to discuss today?
>
> --
> Alex Bennée
>

[Qemu-devel] MTTCG Sync-up call today?

[Alex Bennée]

Hi,

Do we have anything we want to discuss today?

--
Alex Bennée

Re: [Qemu-devel] MTTCG Sync-up call today?

[Mark Burton]

[-- Attachment #1.1: Type: text/plain, Size: 1738 bytes --]

Fred’s away this week too

Cheers
Mark.

> On 25 Apr 2016, at 12:32, alvise rigo <a.rigo@virtualopensystems.com> wrote:
> 
> Hi Alex,
> 
> On Mon, Apr 25, 2016 at 11:53 AM, Alex Bennée <alex.bennee@linaro.org <mailto:alex.bennee@linaro.org>> wrote:
> Hi,
> 
> We are due to have a sync-up call today but I don't think I'll be able
> to make it thanks to a very rough voice courtesy of my
> petri-dishes/children. However since the last call:
> 
>  * Posted final parts of the MTTCG patch set
>  * Lots of reviews
> 
> Please welcome Pranith to the group who is participating as a GSoC
> student. His project will be looking at the modelling of memory barriers
> in MTTCG.
> 
> My plan for the next week is look in more detail at the tb_find_fast
> lock breaking patch. I had to drop it from the original series due to
> regressions but it has a massive effect on performance that means it
> needs sorting. I'll probably start re-building a tree with Emilio's QHT
> patches included which will allow for lockless lookups in the fast path
> and then start re-basing the enabling and ARMv7 patches on top of that.
> 
> I'll also do another review pass of Alvise' LL/SC patches but a fresh
> pair of eyes on them will be appreciated.
> 
> Alvise, how are you doing with the MTTCG version?
> 
> I'm working on this, mostly I'm investigating some issues related to the dirty bitmaps' code that lately changed a bit.
> Apart from that, the branch is almost ready.
> 
> Best regards,
> alvise
> 
> 
> --
> Alex Bennée
> 


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

	+33 (0)603762104
	mark.burton
 <applewebdata://A77A5C98-9405-4FC1-B8FB-404570BC5EA7/www.greensocs.com>




[-- Attachment #1.2: Type: text/html, Size: 4978 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [Qemu-devel] MTTCG Sync-up call today?

[alvise rigo]

[-- Attachment #1: Type: text/plain, Size: 1379 bytes --]

Hi Alex,

On Mon, Apr 25, 2016 at 11:53 AM, Alex Bennée <alex.bennee@linaro.org>
wrote:

> Hi,
>
> We are due to have a sync-up call today but I don't think I'll be able
> to make it thanks to a very rough voice courtesy of my
> petri-dishes/children. However since the last call:
>
>  * Posted final parts of the MTTCG patch set
>  * Lots of reviews
>
> Please welcome Pranith to the group who is participating as a GSoC
> student. His project will be looking at the modelling of memory barriers
> in MTTCG.
>
> My plan for the next week is look in more detail at the tb_find_fast
> lock breaking patch. I had to drop it from the original series due to
> regressions but it has a massive effect on performance that means it
> needs sorting. I'll probably start re-building a tree with Emilio's QHT
> patches included which will allow for lockless lookups in the fast path
> and then start re-basing the enabling and ARMv7 patches on top of that.
>
> I'll also do another review pass of Alvise' LL/SC patches but a fresh
> pair of eyes on them will be appreciated.
>
> Alvise, how are you doing with the MTTCG version?
>

I'm working on this, mostly I'm investigating some issues related to the
dirty bitmaps' code that lately changed a bit.
Apart from that, the branch is almost ready.

Best regards,
alvise


>
> --
> Alex Bennée
>

[-- Attachment #2: Type: text/html, Size: 1980 bytes --]

[Qemu-devel] MTTCG Sync-up call today?

[Alex Bennée]

Hi,

We are due to have a sync-up call today but I don't think I'll be able
to make it thanks to a very rough voice courtesy of my
petri-dishes/children. However since the last call:

 * Posted final parts of the MTTCG patch set
 * Lots of reviews

Please welcome Pranith to the group who is participating as a GSoC
student. His project will be looking at the modelling of memory barriers
in MTTCG.

My plan for the next week is look in more detail at the tb_find_fast
lock breaking patch. I had to drop it from the original series due to
regressions but it has a massive effect on performance that means it
needs sorting. I'll probably start re-building a tree with Emilio's QHT
patches included which will allow for lockless lookups in the fast path
and then start re-basing the enabling and ARMv7 patches on top of that.

I'll also do another review pass of Alvise' LL/SC patches but a fresh
pair of eyes on them will be appreciated.

Alvise, how are you doing with the MTTCG version?

--
Alex Bennée