[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160929195557.GE13257@potion>
Date: Thu, 29 Sep 2016 21:55:57 +0200
From: Radim Krčmář <rkrcmar@...hat.com>
To: Paolo Bonzini <pbonzini@...hat.com>
Cc: linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
yang.zhang.wz@...il.com, feng.wu@...el.com, mst@...hat.com
Subject: Re: [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?
Powered by blists - more mailing lists