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

Anthony Liguori
2007-04-04T14:55:39Z

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