lkml.org 
[lkml]   [2009]   [May]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [GIT PULL] Xen APIC hooks (with io_apic_ops)

* Avi Kivity <avi@redhat.com> wrote:

> Ingo Molnar wrote:
>> * Avi Kivity <avi@redhat.com> wrote:
>>
>>
>>> Ingo Molnar wrote:
>>>
>>>>> We do something similar for Windows (by patching it) very
>>>>> successfully; Windows likes to touch the APIC TPR ~ 100,000 times
>>>>> per second, usually without triggering an interrupt. We hijack
>>>>> these writes, do the checks in guest context, and only exit if
>>>>> the TPR write would trigger an interrupt.
>>>>>
>>>> I suspect you aware of that this is about the io-apic not the local
>>>> APIC. The local apic methods are already driver-ized - and they
>>>> sit closer to the CPU so they matter more to performance.
>>>>
>>> Yeah, I gave this as an example. It's very different -- io-apic vs.
>>> local apic, paravirtualization vs. patching the guest behind its
>>> back, Linux vs. Windows.
>>>
>>> Of course if we hook the io-apic EOI we'll want to hook the local
>>> apic EOI as well.
>>>
>>
>> Yeah. Eventually anything that matters to performance will be
>> accelerated by hardware (and properly virtualized), which in turn
>> will be faster than any hypercall based approach, right?
>
> Right. That's already happened to the TPR (Intel processors
> accelerate that 4-bit registers but ignore everything else in the
> local apic). As another example, we have mmu paravirtualization
> in kvm, but automatically disable it when the hardware does nested
> paging. The problem is that hardware support has a long pipeline,
> and even when support does appear, there's a massive installed
> base to care about.

Yeah. Btw., i also think that in-kernel IO-APIC and APIC emulation
could have uses elsewhere as well - such as in testing. Currently
you actually have to own a big box to be able to test certain
hardware limits. This has a negative effect on test coverage and a
subsequent negative effect on kernel quality. If KVM provided clean
code to emulate certain hw environments we could check out limits
(and our bugs) far more effectively.

Ingo


\
 
 \ /
  Last update: 2009-05-25 07:23    [W:0.147 / U:0.448 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site