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
