[lkml]   [2016]   [Sep]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC PATCH 0/3] kvm: x86: speedups for APICv
2016-09-29 17:41-0400, Paolo Bonzini:
>> And a more far-fetched one: if we know that PI.ON is set before vm
>> entry, we could just send POSTED_INTR_VECTOR self-IPI after masking
>> interrupts and let APICv copy PIR to IRR and deliver interrupts.
>> There are two possible drawbacks: Is the self-IPI overhead too big?
>> Would APICv IRR evaluation at vm entry take precedence, so we'd have big
>> interrupt priority inversion window?
> I don't think there is a risk of inverting interrupt priority, because
> that race is always present. But the overhead is probably too much, the
> cost of the one xchg in __apic_update_irr is probably half of the whole
> IRR update if the PI descriptor cacheline bounces.

Yep, I just ran the vmexit kvm-unit-benchmark -- the cpuid and hypercall
tests are ~1000 cycles slower if I send the notification self-IPI, which
should be far more than PIR->IRR + vmcs_write(RVI, fls(IRR)).

 \ /
  Last update: 2016-09-30 15:33    [W:0.069 / U:0.496 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site