Received: by 10.192.165.148 with SMTP id m20csp1853865imm; Thu, 26 Apr 2018 03:18:32 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+4wv13n6t6cacNYOB2eyHl+Qo+vUf0MzvmW+n9tOx1Xyp9MN86ZfldJXWkQADER2r4ZqGu X-Received: by 10.101.67.203 with SMTP id n11mr19488607pgp.287.1524737912276; Thu, 26 Apr 2018 03:18:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524737912; cv=none; d=google.com; s=arc-20160816; b=Oyx8W9tXUwiVHXJfvpgE8tJOUae2Cw90E3p5XjzTgdZ6SeJaLTL8Xrs51QdxBABBk7 cHFEmSvsXmf2/oSbMq8LozDBeNzIV6k9geW71rn30fH01GSmEmgSgtmIxRTmMupt13qQ ZuRPautU1mSOusNidF6VorhWUppqRPDWdQjIDtTCYProVezRrFqvzZFmDgaWU17wGR/o Tu2q9L4ior/O8BodNpEpOsx1raTfUql1yWHE4GUy9X3HR6Srjf5ETACBrQsBhM/NjHuN reWPsugApat5MtlW7wM3iMRQhcPSTdaX4u9FjKyU1Oc+tDcSNEkrTMXdIyE+8qV1inWW FH5A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=De2PHFUjfORPVwJNZa73DStKo3PaIuHftG2haSba1/0=; b=RX97pZjfrxIhAwYDzEM7vro7w4eeST+wmZtY2CVwVhBuPZQGyBFz1koKWSu265vfFj tbYOPqGMIthJOPdslw8ioA8xGLaaFKUsn7fTvPbjFsZJWtYcr7+TfoBdrJ+XPPnm2+1e BSKuZD9E5miabvqAsvccEwbD+lftVT2tQPhPGSHJ49FZcs/YuDUrvJuo9cbJBNUOhKRz 8SkEI2qj5aQ3nwFpqXkZ0XYpuDkCN4DMgbSB7MB3S4SZqD68MBzcz+rfAU+q1ccUiioP VWxdbMUb0ZlH6iXdPG8S687bokZ/PEwPH+XlrHQYkQXlQb9nnJIhQWlyC8Y+sc+jqKE4 pKtA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h8-v6si583952pls.502.2018.04.26.03.18.17; Thu, 26 Apr 2018 03:18:32 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754900AbeDZKRH (ORCPT + 99 others); Thu, 26 Apr 2018 06:17:07 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:50694 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754428AbeDZKRC (ORCPT ); Thu, 26 Apr 2018 06:17:02 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 42F0415AD; Thu, 26 Apr 2018 03:17:02 -0700 (PDT) Received: from localhost (unknown [10.37.12.162]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A41553F487; Thu, 26 Apr 2018 03:17:01 -0700 (PDT) Date: Thu, 26 Apr 2018 12:16:59 +0200 From: Christoffer Dall To: Auger Eric Cc: eric.auger.pro@gmail.com, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu, marc.zyngier@arm.com, cdall@kernel.org, peter.maydell@linaro.org, andre.przywara@arm.com, drjones@redhat.com, wei@redhat.com Subject: Re: [PATCH v3 09/12] KVM: arm/arm64: Check all vcpu redistributors are set on map_resources Message-ID: <20180426101659.GD19872@C02W217FHV2R.local> References: <1523607658-9166-1-git-send-email-eric.auger@redhat.com> <1523607658-9166-10-git-send-email-eric.auger@redhat.com> <20180424210809.GJ4533@C02W217FHV2R.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 26, 2018 at 11:56:10AM +0200, Auger Eric wrote: > > > On 04/24/2018 11:08 PM, Christoffer Dall wrote: > > On Fri, Apr 13, 2018 at 10:20:55AM +0200, Eric Auger wrote: > >> On vcpu first run, we eventually know the actual number of vcpus. > >> This is a synchronization point to check all redistributors regions > >> were assigned. > > > > Isn't it the other way around? We want to check that all redistributors > > (one for every VCPU) has its base address set? (I don't suppose we care > > about unused redistributor regions). > Yes I meant "to check all redistributors were assigned" > > > >> On kvm_vgic_map_resources() we check both dist and > >> redist were set, eventually check potential base address inconsistencies. > > > > Do we need to check that again? Didn't we check that at > > creation/register time? > Yes we need to, to handle the case where the userspace does not provide > sufficient rdist region space > > create 8 vcpus (no iodev registered) > define a redist region for 4 (4 iodevs registered) > start the vcpus > > > >> > >> Signed-off-by: Eric Auger > >> --- > >> virt/kvm/arm/vgic/vgic-v3.c | 19 ++++++++++++++----- > >> 1 file changed, 14 insertions(+), 5 deletions(-) > >> > >> diff --git a/virt/kvm/arm/vgic/vgic-v3.c b/virt/kvm/arm/vgic/vgic-v3.c > >> index b80f650..feabc24 100644 > >> --- a/virt/kvm/arm/vgic/vgic-v3.c > >> +++ b/virt/kvm/arm/vgic/vgic-v3.c > >> @@ -484,16 +484,25 @@ struct vgic_redist_region *vgic_v3_rdist_region_from_index(struct kvm *kvm, > >> > >> int vgic_v3_map_resources(struct kvm *kvm) > >> { > >> - int ret = 0; > >> struct vgic_dist *dist = &kvm->arch.vgic; > >> - struct vgic_redist_region *rdreg = > >> - list_first_entry(&dist->rd_regions, > >> - struct vgic_redist_region, list); > >> + struct kvm_vcpu *vcpu; > >> + int ret = 0; > >> + int c; > >> > >> if (vgic_ready(kvm)) > >> goto out; > >> > >> - if (IS_VGIC_ADDR_UNDEF(dist->vgic_dist_base) || !rdreg) { > >> + kvm_for_each_vcpu(c, vcpu, kvm) { > >> + struct vgic_cpu *vgic_cpu = &vcpu->arch.vgic_cpu; > >> + > >> + if (IS_VGIC_ADDR_UNDEF(vgic_cpu->rd_iodev.base_addr)) { > >> + kvm_err("vcpu %d redistributor base not set\n", c); > > > > Shouldn't this be a kvm_debug instead? I think the user can just > > provoke this by failing to register enough redistributor regions. > yes indeed. > > > > I'm also wondering if we could check this on vgic_init time for gicv3, > > which should have a defined vgic init ordering requirement. That would > > make debugging it slightly easier to debug than "my machine isn't > > starting, and I get -ENXIO, and it can mean anything". > > Well at vgic_init time, vcpus are frozen but dist and redist regions are > not forced to be set, hence the late check we do in map_resources, on > 1st VCPU run. Not sure I get this one? > I thought we required userspace to register the redist regions before initializing the vgic, but if there is no defined order there, then fine. (Although I'm getting the feeling we should have been more strict on our ordering requirement, and that the whole "you can create anything you want in any order you want" makes the kernel implementation really complex. I may be reversing my own oppinion on this matter here.) Thanks, -Christoffer