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

Anthony Liguori
2007-04-04T16:09:22Z

Avi Kivity wrote:
> Anthony Liguori wrote:
>>> Maybe some brave soul can hack kvm to patch the new instruction in
>>> place of the mmio instruction Windows uses to bang on the tpr.
>>
>> It seems like that shouldn't be too hard assuming that the MMIO
>> instructions are <= the new CR8 instruction. It would require
>> knowing where the TPR is mapped into memory of course.
>
> Well, we know the physical address (some msr) and the virtual
> mapping. But we must be sure that the instruction is only used for
> setting the tpr, and not other registers.
>
> Er, thinking a bit more, cr8 is just 4 bits (and no, not the least
> significant) out of the 8-bit tpr, so it doesn't work without serious
> hackery.

Hrm, so this not nearly as straight forward as I initially hoped :-/

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

Regards,

Anthony Liguori