From mboxrd@z Thu Jan 1 00:00:00 1970 From: Radim =?utf-8?B?S3LEjW3DocWZ?= Subject: Re: [PART1 RFC v2 10/10] svm: Manage vcpu load/unload when enable AVIC Date: Mon, 14 Mar 2016 17:54:22 +0100 Message-ID: <20160314165422.GA10013@potion.brq.redhat.com> References: <1457124368-2025-1-git-send-email-Suravee.Suthikulpanit@amd.com> <1457124368-2025-11-git-send-email-Suravee.Suthikulpanit@amd.com> <20160309214629.GE19459@potion.brq.redhat.com> <20160310140141.GA23501@potion.brq.redhat.com> <56E6A74D.8090807@amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: pbonzini@redhat.com, joro@8bytes.org, bp@alien8.de, gleb@kernel.org, alex.williamson@redhat.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, wei@redhat.com, sherry.hurwitz@amd.com To: Suravee Suthikulpanit Return-path: Content-Disposition: inline In-Reply-To: <56E6A74D.8090807@amd.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org 2016-03-14 18:58+0700, Suravee Suthikulpanit: > On 03/10/2016 09:01 PM, Radim Kr=C4=8Dm=C3=A1=C5=99 wrote: >>Well, we haven't reached an agreement on is_running yet. The situati= on: >>if we don't unset vcpu1.is_running when vcpu1 is scheduled out and vc= pu2 >>gets scheduled on vcpu1's physical core, then vcpu2 would receive a >>doorbell intended to vcpu1. >=20 > That's why, in V2, I added the logic to check if the is_running bit i= s set > for the current vcpu (e.g. vcpu1) when unloaded, then restore the bit= during > loading later of if it was set during previous unloaded. This way, wh= en we > load the new vcpu (e.g. vcpu2), the is_running will be set as it was = before > unloading. Yes, that's a good solution and I'm leaning towards it. The downside i= s that IPIs from other VCPUs exit, even though KVM can't do anything, because the vCPU is already going to run as soon as it can. Keeping is_running set during unload would prevent meaningless exits. >>We'd like to keep is_running set when there is no reason to vmexit, b= ut >>not if a guest can negatively affect other guests. >=20 > Not sure how this can affect other guests? If is_running is set, then the doorbell is sent to a physical core, so any running task/vCPU will receive it. This is safe, but a difference can be seen in performance. >>How does receiving a stray doorbell affect the performance? >=20 > As far as I know, the doorbell only affects the CPU during vmrun. Yeah, I guess that receiving a doorbell outside of vmrun has no overhead. > Onc= e > received, it will check the IRR in vAPIC backing page. So, I think i= f IRR > bit is not set, the affect should be rather minimal. Even empty IRR still needs to be rescanned every time a doorbell arrives, which might affect the execution pipeline. After re-reading all relevant quotes, I think that hardware wasn't designed with this use in mind, so it's safer to assume an adverse effect and go with solution we have now. (It'd be hard to measure anyway.) Sorry for the tangent.