| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
[Xen-devel] Re: [GIT PULL] Xen APIC hooks (with io_apic_ops)
* Avi Kivity <avi@xxxxxxxxxx> wrote:
> Ingo Molnar wrote:
>> * Avi Kivity <avi@xxxxxxxxxx> 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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home