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

[Avi Kivity <avi@redhat.com>]

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