From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1426481AbcBRPoA (ORCPT ); Thu, 18 Feb 2016 10:44:00 -0500 Received: from mx1.redhat.com ([209.132.183.28]:46587 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1425136AbcBRPn7 (ORCPT ); Thu, 18 Feb 2016 10:43:59 -0500 Date: Thu, 18 Feb 2016 16:43:44 +0100 From: Radim =?utf-8?B?S3LEjW3DocWZ?= To: Paolo Bonzini Cc: Suravee Suthikulpanit , joro@8bytes.org, alex.williamson@redhat.com, gleb@kernel.org, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, wei@redhat.com, sherry.hurwitz@amd.com Subject: Re: [PART1 RFC 5/9] svm: Add VMEXIT handlers for AVIC Message-ID: <20160218154343.GA18904@potion.brq.redhat.com> References: <1455285574-27892-6-git-send-email-suravee.suthikulpanit@amd.com> <56BDFC72.7030905@redhat.com> <56C2C1BF.7010700@amd.com> <56C312E1.1080902@redhat.com> <20160216141330.GG10555@potion.brq.redhat.com> <56C354A5.4040807@redhat.com> <20160216180618.GA18952@potion.brq.redhat.com> <56C52B80.5050104@amd.com> <20160218141817.GA6289@potion.brq.redhat.com> <56C5DA62.8080204@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <56C5DA62.8080204@redhat.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 2016-02-18 15:51+0100, Paolo Bonzini: > On 18/02/2016 15:18, Radim Krčmář wrote: >> KVM just has to make sure that targeted VCPUs notice the interrupt, >> which means to kick (wake up) VCPUs that don't have IsRunning set. >> There is no need to do anything with running VCPUs, because they >> - are in guest mode and noticed the doorbell >> - are in host mode, where they will >> 1) VMRUN as fast as they can because the VCPU didn't want to halt >> (and IRR is handled on VMRUN) >> 2) check IRR after unsetting IsRunning and goto (1) if there are >> pending interrupts. (RFC doesn't do this, which is another bug) > > This is not necessary. IsRunning is only cleared at vcpu_put time. It's not necessary if we are being preempted, but it is necessary to clear IsRunning earlier when we are going to block (i.e. after a halt). > The > next KVM_RUN will look at IRR (kvm_arch_vcpu_runnable), if necessary set > the mp_state to KVM_MP_STATE_RUNNABLE, and do the VMRUN. We're not always going to exit to userspace. I think the following order of actions could result in a stuck VM: (The main idea is that VCPU targets another VCPU between its last check for IRR and clearing of IsRunning.) 1) vcpu0 has set IsRunning and is in guest mode. 2) vcpu0 executes HLT and exits guest mode. 3) vcpu0 doesn't have any pending interrupts or other stuff that would make kvm_arch_vcpu_runnable() return true. 4) vcpu0 runs kvm_vcpu_block() and gets to call schedule(). 5) *vcpu1* sends IPI to vcpu0. IsRunning is set on vcpu0, so AVIC doesn't exit. A doorbell is sent, but it does nothing. 6) vcpu0 runs schedule() and clears IsRunning in a callback.