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

Dor Laor
2007-04-04T16:23:58Z

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

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

>Regards,
>
>Anthony Liguori