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

[Anthony Liguori <anthony@codemonkey.ws>]

On 02/09/2010 08:38 AM, Avi Kivity wrote:
> 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().

Yes.  But just as you mention, we have to approach it on a 
device-by-device basis and incrementally convert over devices.

>   We also have some lock inversion since hpet calls the timer but the 
> timers also call hpet.

Right.  Making the dispatch loop in the IO thread thread safe won't be 
so bad either :-)

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

It's certainly not easy but I don't think it's impossibly hard.

Regards,

Anthony Liguori