Re: [Qemu-devel] Re: KVM call agenda for Feb 9

Avi Kivity
2010-02-09T14:38:32Z

On 02/09/2010 04:18 PM, Anthony Liguori wrote:
> On 02/09/2010 02:52 AM, Jan Kiszka wrote:
>> Alexander Graf wrote:
>>> On 09.02.2010, at 07:56, Avi Kivity wrote:
>>>> - rcuify/fine-grain qemu locks
>>> And this should be done either way, but is probably not a short-term
>>> goal.
>>>
>> Indeed. We won't get around this longterm as it is a scalability
>> bottleneck and a killer for RT guest load. We can't push everything into
>> the kernel. Qemu needs a smart plan how to gradually convert its CPU and
>> device model to fine-grained locking.
>
> The VCPU loops should be easy to convert to lockless operation. It's
> easier to do this upstream but that requires a functioning IO thread.
>
> For the table based MMIO and PIO dispatch, RCU would be a good locking
> choice since these structures are rarely updated. The tricky bit is
> that the APIC has to be converted over to lockless before any other
> device can be converted because just about every device wants to
> inject an interrupt.

The problem is that all the internal APIs now have to be threaded.
Looking at hpet as a simple example, we have qemu_irq_pulse() and
qemu_mod_timer(). We also have some lock inversion since hpet calls the
timer but the timers also call hpet. qemu_irq_pulse() feeds the various
interrupt controllers; not a problem for kernel irqchip but nontrivial
for qemu's ioapic and pic.

I'm not saying we should push hpet into the kernel to save userspace
coding effort; there should be an independent reason to do this. But I
don't think threading qemu is going to be anything near easy.

--
error compiling committee.c: too many arguments to function