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

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

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

> The strength of these arguments increase as vmexit overhead decreases 
> with improving hardware.

Do you mean, the strength of these arguments decrease? :-)

>
> 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
- Maintaining hardware emulation in two places is going to suck
- The need to have in-kernel backends for paravirt drivers should be 
carefully considered.

An in-kernel backend is certainly not necessary for disks.  If we can't 
drive network traffic fast enough from userspace, perhaps we should 
consider improving the userspace 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.

Regards,

Anthony Liguori


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