Re: QEMU PIC indirection patch for in-kernel APIC work

Anthony Liguori
2007-04-04T16:48:13Z

Dor Laor wrote:
>>>> If we do this, then we can probably just handle the TPR as a special
>>>> case anyway and not bother returning to userspace when the TPR is
>>>> updated through MMIO. That saves the round trip without adding
>>>> emulation complexity.
>>>>
>>> That means the emulation is split among user space and kernel. Not
>>> nice. One of the advantages of moving the entire thing is that it is
>>> at least clearly defined.
>>>
>> It still exists in userspace. Having the code duplication (especially
>> when it's not the same code base) is unfortunate. Plus, it complicates
>> save/restore/migration since now some device state is in the kernel.
>>
> It
>
>> further complicates things if you want to make sure that KVM saved
>> images are loadable in QEMU (you have to make sure that the device
>>
> state
>
>> is identical for the kernel and userspace). Special casing the TPR
>> emulation seems like the lesser of two evils to me.
>>
>>
>
> There are still some nasty issues that caused by running apic in qemu:
> - If you have a PV driver that issued an irq and now it needs another
> one,
> You cannot really be sure if the first one was injected. You can hold
>
> extra state and follow irq injection from qemu but this is ugly.
> - You have to keep sync of tpr and irq injection: suppose apic needs to
>
> inject an irq, it pops it from the irr and tries to inject it. If it
> is
> done while the VM is in interrupt window closed or irq disables it
> will
> no happen instantly. When the irq would really be injected the tpr
> might
> be different, causing windows irq-not-less-or-equal BSOD.
> This is especially true for injecting several irq at once.
>
> Keeping the apic in the kernel simplifies this with the cost of
> maintaining an apic/pic implementation.
>

Hrm, this is definitely starting to sound like a PITA to deal with.
Maybe in-kernel platform devices are unavoidable :-/

> Do you know why Xen guy choose of implementing it in Xen? Why didn't
> they rip Qemu implementation?
>

I believe it's based on the QEMU implementation although it's evolved
quite a bit. Jun can probably provide a better answer.

Regards,

Anthony Liguori

>
>> Regards,
>>
>> Anthony Liguori