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

["Edgar E. Iglesias" <edgar.iglesias@xilinx.com>]

On Fri, Sep 04, 2015 at 11:25:33AM +0200, Paolo Bonzini wrote:
> 
> 
> 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. :)

Hi!

IMO it would be nice if we could run the cores in some kind of lock-step
with a configurable amount of instructions that they can run ahead
of time (X).

For example, if X is 10000, every thread/core would checkpoint at
10000 insn boundaries and wait for other cores. Between these
checkpoints, the cores will not be in sync. We might need to
consider synchronizing at I/O accesses aswell to avoid weird
timing issues when reading counter registers for example.

Of course the devil will be in the details but an approach roughly
like that sounds useful to me.

Are there any other ideas floating around that may be better?

BTW, where can I find the latest series? Is it on a git-repo/branch
somewhere?

Best regards,
Edgar