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 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?
