Re: [Qemu-devel] MTTCG Tasks (kvmforum summary)

[Paolo Bonzini]

On 04/09/2015 09:49, Alex Bennée wrote:
> * Signal free qemu_cpu_kick (Paolo)
> 
> I don't know much about this patch set but I assume this avoids the need
> to catch signals and longjmp about just to wake up?

It was part of Fred's patches, so I've extracted it to its own series.
Removing 150 lines of code can't hurt.

> * Memory barrier support (need RFC for discussion)
> 
> I came to KVM forum with a back of the envelope idea we could implement
> one or two barrier ops (acquire/release?). Various suggestions of other
> types of memory behaviour have been suggested.
> 
> I'll try to pull together an RFC patch with design outline for
> discussion. It would be nice to be able to demonstrate barrier failures
> in my test cases as well ;-)

Emilio has something about it in his own MTTCG implementation.

> * longjmp in cpu_exec
> 
> Paolo is fairly sure that if you take page faults while IRQs happening
> problems will occur with cpu->interrupt_request. Does it need to take
> the BQL?
> 
> I'd like to see if we can get a torture test to stress this code
> although it will require IPI support in the unit tests.

It's x86-specific (hardware interrupts push to the stack and can cause a
page fault or other exception), so a unit test can be written for it.

> * tlb_flush and dmb behaviour (am I waiting for TLB flush?)
> 
> I think this means we need explicit memory barriers to sync updates to
> the tlb.

Yes.

> * tb_find_fast outside the lock
> 
> Currently it is a big performance win as the tb_find_fast has a lot of
> contention with other threads. However there is concern it needs to be
> properly protected.

This, BTW, can be done for user-mode emulation first, so it can go in
early.  Same for RCU-ized code_gen_buffer.

> * What to do about icount?
> 
> What is the impact of multi-thread on icount? Do we need to disable it
> for MTTCG or can it be correct per-cpu? Can it be updated lock-step?
> 
> We need some input from the guys that use icount the most.

That means Edgar. :)

Paolo