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

[Anthony Liguori <anthony-rdkfGonbjUSkNkDKm+mE6A@public.gmane.org>]

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


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV