[Top][All Lists]

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

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

From: Anthony Liguori
Subject: Re: [Qemu-devel] Re: KVM call agenda for Feb 9
Date: Tue, 09 Feb 2010 09:08:37 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20091209 Fedora/3.0-4.fc12 Lightning/1.0pre Thunderbird/3.0

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.


Anthony Liguori

reply via email to

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