qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [patch 1/2] qemu: sem/thread helpers


From: Anthony Liguori
Subject: Re: [Qemu-devel] [patch 1/2] qemu: sem/thread helpers
Date: Wed, 11 Mar 2009 11:56:21 -0500
User-agent: Thunderbird 2.0.0.19 (X11/20090105)

Paul Brook wrote:
+QemuSem qemu_sem;

It's entirely unclear what is actually protected by the semaphore.

What exactly does the IO thread do? AFAICS device MMIO is still run from within the CPU thread. Device code is not threadsafe (and probably never will be), so you can't run any of the device callbacks in the IO thread either. Doesn't seem like there's a lot left for it to do...

The goal is to drop qemu_mutex while the VCPU is running to allow the device model to run while the VCPU executes. This is not currently safe with TCG but it is safe when using KVM.

There are a couple reasons to drop qemu_mutex while running the VCPU. When using KVM's in-kernel APIC, hlt emulation occurs within the kernel. This means that the KVM_RUN ioctl blocks indefinitely. We currently don't use in-kernel APIC emulation in upstream QEMU's KVM support as this set of patches is a pre-requisite for that.

This also enables true SMP support in KVM. You can allow multiple VCPUs to run concurrently once you're dropping qemu_mutex during VCPU execution.

The VCPU threads have to acquire qemu_mutex once they drop back to QEMU (to handle MMIO, for instance), but this only happens during IO.

From an infrastructure perspective, this is a feature for KVM but also a step in a better direction for TCG too. If TCG can be made to allow qemu_mutex to be dropped (perhaps for x86->x86 translation, as a start), then the same infrastructure can be used for true SMP support with TCG.

Once we have this, we can start making some of the device model code thread safe too...

Regards,

Anthony Liguori

Regards,

Anthony Liguori

Paul





reply via email to

[Prev in Thread] Current Thread [Next in Thread]