lkml.org 
[lkml]   [2016]   [Sep]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC PATCH 0/3] kvm: x86: speedups for APICv
    2016-09-27 23:20+0200, Paolo Bonzini:
    > The difficult one is patch 2. I find the new code easier to follow than
    > the old one, but it doesn't mean it works. :) The aim is for APICv to
    > not use KVM_REQ_EVENT at all for interrupts, therefore turning APICv's
    > weakness (having to look at PIR on every vmentry) into a strength
    > (because checking PIR.ON is cheaper than processing KVM_REQ_EVENT).

    Makes sense.

    Another possible optimization: when delivering an IPI, don't write the
    vector to PIR, but directly to VIRR. If the guest is not in VMX
    non-root mode, then vm entry will take care of the injection; in the
    other case, we'll send POSTED_INTR_VECTOR.
    It seems that we don't even have to set PI.ON -- SDM doesn't say it is
    necessary to evaluate pending virtual interrupts after receiving the
    notification interrupt. If we have to set PI.ON, we can just skip the
    PIR->VIRR sync as long as the VM doesn't have an assigned device,
    because we know that PIR is empty.

    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?

    \
     
     \ /
      Last update: 2016-09-29 21:56    [W:4.296 / U:0.416 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site