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

[Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>]

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.


>> The strength of these arguments increase as vmexit overhead decreases 
>> with improving hardware.
>
> Do you mean, the strength of these arguments decrease? :-)

Nope, increase.  Currently vmexit time dominates the privilege switch 
time to user mode.  If vmexit time is reduced to be on par with syscall 
time, you get 50% saving (assuming tpr emulation is near-free, which it 
can be easily made to be).

>
>>
>> Of course, pushing such a piece of misery into the kernel where it 
>> can cause much pain should not be done lightly.
>
> Right, so some arguments against:
> - The cost to go to userspace is small compared to the cost of the 
> exit itself

True now.  False tomorrow (for some value of tomorrow).

> - Maintaining hardware emulation in two places is going to suck

True now.  Even truer tomorrow.

> - The need to have in-kernel backends for paravirt drivers should be 
> carefully considered.
>
> An in-kernel backend is certainly not necessary for disks.  

Agree.

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

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

-- 
error compiling committee.c: too many arguments to function


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