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

Anthony Liguori
2007-04-04T15:51:47Z

Avi Kivity wrote:
> Anthony Liguori wrote:
>> Avi Kivity wrote:
>>> Anthony Liguori wrote:
>>>>
>>>> Then again, are we really positive that we have to move the APIC
>>>> into the kernel? A lot of things will get much more complicated.
>>>
>>> The following arguments are in favor:
>>> - allow in-kernel paravirt drivers to interrupt the guest without
>>> going through qemu (which involves a signal and some complexity)
>>> - same for guest SMP IPI
>>> - reduced overhead for a much-loved hardware component (especially
>>> on Windows, where one regularly sees 100K apic updates a second)
>>
>> This is for the TPR right? VT has special logic to handle TPR
>> virtualization doesn't it? I thought SVM did too...
>>
>
> Yes, the TPR. Both VT and SVM virtualize CR8 in 64-bit mode. SVM
> also supports CR8 in 32-bit mode through a nwe instruction encoding,
> but nobody uses that to my knowledge. 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.

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.

>> If we can't drive network traffic fast enough from userspace, perhaps
>> we should consider improving the userspace interfaces.
>
> I'm open to suggestions. With an in-kernel backend, we can have
> copyless transmit and single-copy receive. With the current APIs, we
> can have single-copy transmit and 3-copy receive. I doubt we could
> improve it beyond (1, 2) without major hacking on non-kvm kernel
> interfaces.

I don't know enough about networking to speak intelligently here so I'll
just defer to the experts :-)

Regards,

Anthony Liguori

>>
>> Originating disk IO from userspace is useful for support interesting
>> storage formats. Network IO from userspace is also interesting to
>> support things like slirp.
>
> Right. Nobody's suggesting removing it, however.