From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753197AbdDLAPT convert rfc822-to-8bit (ORCPT ); Tue, 11 Apr 2017 20:15:19 -0400 Received: from mx1.redhat.com ([209.132.183.28]:38956 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752327AbdDLAPQ (ORCPT ); Tue, 11 Apr 2017 20:15:16 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com A3F8D3D970 Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=pbonzini@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com A3F8D3D970 Date: Tue, 11 Apr 2017 20:15:15 -0400 (EDT) From: Paolo Bonzini To: Radim =?utf-8?B?S3LEjW3DocWZ?= Cc: James Hogan , linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Christoffer Dall , Andrew Jones , Marc Zyngier , Christian Borntraeger , Cornelia Huck , Paul Mackerras Message-ID: <1614033008.12916030.1491956115175.JavaMail.zimbra@redhat.com> In-Reply-To: <20170411204536.GA20384@potion> References: <20170406202056.18379-1-rkrcmar@redhat.com> <20170406202056.18379-2-rkrcmar@redhat.com> <20170406210215.GV31606@jhogan-linux.le.imgtec.org> <20170411204536.GA20384@potion> Subject: Re: [PATCH RFC 1/6] KVM: fix guest_mode optimization in kvm_make_all_cpus_request() MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT X-Originating-IP: [10.4.164.1, 10.4.195.2] Thread-Topic: fix guest_mode optimization in kvm_make_all_cpus_request() Thread-Index: 5bYHZ106OgKat/9VvoOMG3S4f3l1DQ== X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Wed, 12 Apr 2017 00:15:15 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org ----- Original Message ----- > From: "Radim Krčmář" > To: "Paolo Bonzini" > Cc: "James Hogan" , linux-kernel@vger.kernel.org, kvm@vger.kernel.org, "Christoffer Dall" > , "Andrew Jones" , "Marc Zyngier" , "Christian > Borntraeger" , "Cornelia Huck" , "Paul Mackerras" > > Sent: Wednesday, April 12, 2017 4:45:36 AM > Subject: Re: [PATCH RFC 1/6] KVM: fix guest_mode optimization in kvm_make_all_cpus_request() > > > void kvm_reload_remote_mmus(struct kvm *kvm) > > { > > - kvm_make_all_cpus_request(kvm, KVM_REQ_MMU_RELOAD); > > + /* FIXME, is wait=true really needed? */ > > Probably not. There are two uses, > > in kvm_mmu_prepare_zap_page(): > The only change that happens between kvm_reload_remote_mmus() and > kvm_flush_remote_tlbs() in kvm_mmu_commit_zap_page() is setting of > sp->role.invalid -- synchronizing it doesn't prevent any race with > READING_SHADOW_PAGE_TABLES mode and the unconditional TLB flush is the > important one. I think that kvm_reload_remote_mmus doesn't even need > to kick in this case. > > in kvm_mmu_invalidate_zap_all_pages(): > Same situation: the guest cannot do an entry without increasing the > generation number, but can enter READING_SHADOW_PAGE_TABLES mode > between reload and flush. > I think that we don't need to call > > but my knowledge of this area is obviously lacking ... Yes, you're right - I just was too lazy. :) > > + kvm_make_all_cpus_request(kvm, KVM_REQ_MMU_RELOAD, true); > > } > > > > int kvm_vcpu_init(struct kvm_vcpu *vcpu, struct kvm *kvm, unsigned id) > > > > > > Other users do not need wait=false. > > You mean "wait=true"? > > (Would be safer to assume they depend on the VM exit wait until proved > otherwise ...) Yeah, I audited them. > > - bit 9 = kick after making request > > Maybe add bit mask to denote in which modes the kick/wait is necessary? > > bit 9 : IN_GUEST_MODE > bit 10 : EXITING_GUEST_MODE > bit 11 : READING_SHADOW_PAGE_TABLES > > TLB_FLUSH would set bits 8-11. IIUC, ARM has use for requests that need > to make sure that the guest is not in guest mode before proceeding and > those would set bit 8-10. No, checking vcpu->requests after setting IN_GUEST_MODE is done separately. EXITING_GUEST_MODE's meaning *is* "no IPI needed". > The common requests, "notice me as soon as possible", would set bit 9. > The bits 9-11 could also be used only when bit 8 is set, to make the > transition easier. (9 and 10 could be squished then as well.) Maybe, depending on how the code looks like. But considering we have to do the cmpxchg, I think the should_kick and should_wait logic should be embedded in kvm_make_all_cpus_request (and later on, kvm_make_request). Paolo