On Thu, Nov 12, 2009 at 02:37:26AM +0800, Scott Tsai wrote: > On Thu, Nov 12, 2009 at 2:09 AM, Michael S. Tsirkin <m...@redhat.com> wrote: > >> I do have a newbie question, when exactly would vrtio have to handle > >> concurrent access from multiple threads? > >> My current reading of the code suggests: > >> 1. when CONFIG_IOTHREAD is true > >> 2. when CONFIG_KVM is true and the guest machine has multiple CPUs > > > > Right. I don't think CONFIG_IOTHREAD can work correctly > > without kvm though: how would atomics be handled? > > I naively imagined it to work like this: > When CONFIG_IOTHREAD is true and CONFIG_KVM is false, > all the tcg CPUs run in the tcg_cpu_thread and device emulation code > runs in io_thread, > so if the tcg translators generate suitable memory barrier > instructions when it sees a "lfence", "sfence", "mfence" instruction > while emulating a x86 or "sync" while emulating a MIPS everything > should work
that might not be enough. guest can do e.g. atomics on the same memory with iothread. In parctice, with virtio it doesn't. > but a quick look at target-*/translate.c suggests memory > barrier instructions are treated as nops. > > So maybe --enable-io-thread while --disable-kvm should not be allowed > at configure time. > Does anyone actually ship qemu with CONFIG_IOTHREAD enabled?
