Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp343674pxb; Wed, 20 Jan 2021 08:17:48 -0800 (PST) X-Google-Smtp-Source: ABdhPJxQK7spsvIgB1Mr8wsuv+KZpkIqzsZh1KTQwI/syizmLSpwq5L1iO0JMD9ntbNOivLzSBUB X-Received: by 2002:a05:6402:95a:: with SMTP id h26mr5847367edz.288.1611159468087; Wed, 20 Jan 2021 08:17:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1611159468; cv=none; d=google.com; s=arc-20160816; b=Pk6aGmBkBafY5/WbriCIwNicy/YUIfIg4D00o7MgvMp8p74lUfq39737uy3JA000uY 9KocJj2In9G7AdJell8a3bPfkgp5l7yWYnSlWfh52kDYbEZtl1YAJuYQ0oQL2VlvQSxP OC7U94pBFYvi6X41OArkVc+b6auA4GXTPlqQSYnmFF61EdF282MdbAkdlDK3Uw5oM0Qz mKnAUP+YkVokalRebhLNUbK981TwX2NygpCTciPihlPeBiDA6Y4Gg899zB1zWU8TFPRT dqITekgeZRoNsgj/srGyFm9QG8RJnE0RCJWHt0bEf1NkgvTCn8Ia4/fJl0nhtX/09iBy giog== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-language:content-transfer-encoding :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=4LzbEnFnxR12CG9BEAJoD6QO8JmLJ2WtezpoCGcLbpU=; b=Z7h/LukrSeE3jMJe/gdwq+cIqUdsfujiF9Ve6/oHWbn+CW03KCAMrEfRO6tKcvIovr iOzZBxSDSd+QIc2MwpJTLqTpKzFyuqNMwExt3sXSBWWLpGSlV4HJ79JGMNRXuQu3kIZg Rl3fK0fuMIrWeUOZ2jed25ZJKTFzl8njisQY6C1owDov9RCXu7SLP7MNJjZ47RMGcrn+ LETxKShuMsE5Nmo9OgMmkqSjUitIAg9vz+j3yZWHxOd2ucaOEkln/x1aASZ5zjTwF8ui muE+NevDFbnmG4V8lDssqT/VmM0A2XgQlH1WZYwKWoU4ujdNlpOSueAkV90UCT3V+qop 0kjg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g23si822875ejo.55.2021.01.20.08.17.22; Wed, 20 Jan 2021 08:17:48 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2391351AbhATQPN (ORCPT + 99 others); Wed, 20 Jan 2021 11:15:13 -0500 Received: from foss.arm.com ([217.140.110.172]:42116 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2391346AbhATQOX (ORCPT ); Wed, 20 Jan 2021 11:14:23 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id F18F6101E; Wed, 20 Jan 2021 08:13:31 -0800 (PST) Received: from [192.168.0.110] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 6E9873F68F; Wed, 20 Jan 2021 08:13:30 -0800 (PST) Subject: Re: [PATCH 8/9] KVM: arm64: vgic-v3: Expose GICR_TYPER.Last for userspace To: Auger Eric , eric.auger.pro@gmail.com, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu, maz@kernel.org, drjones@redhat.com Cc: james.morse@arm.com, julien.thierry.kdev@gmail.com, suzuki.poulose@arm.com, shuah@kernel.org, pbonzini@redhat.com References: <20201212185010.26579-1-eric.auger@redhat.com> <20201212185010.26579-9-eric.auger@redhat.com> <45a364ec-eac6-a04b-9654-e97970186839@arm.com> <7078b0a5-fb18-5e65-953a-8a55009aa2be@redhat.com> From: Alexandru Elisei Message-ID: Date: Wed, 20 Jan 2021 16:13:31 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 MIME-Version: 1.0 In-Reply-To: <7078b0a5-fb18-5e65-953a-8a55009aa2be@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Eric, On 1/14/21 10:16 AM, Auger Eric wrote: > Hi Alexandru, > > On 1/12/21 6:02 PM, Alexandru Elisei wrote: >> Hi Eric, >> >> On 12/12/20 6:50 PM, Eric Auger wrote: >>> Commit 23bde34771f1 ("KVM: arm64: vgic-v3: Drop the >>> reporting of GICR_TYPER.Last for userspace") temporarily fixed >>> a bug identified when attempting to access the GICR_TYPER >>> register before the redistributor region setting but dropped >>> the support of the LAST bit. This patch restores its >>> support (if the redistributor region was set) while keeping the >>> code safe. >> I suppose the reason for emulating GICR_TYPER.Last is for architecture compliance, >> right? I think that should be in the commit message. > OK added this in the commit msg. >>> Signed-off-by: Eric Auger >>> --- >>> arch/arm64/kvm/vgic/vgic-mmio-v3.c | 7 ++++++- >>> include/kvm/arm_vgic.h | 1 + >>> 2 files changed, 7 insertions(+), 1 deletion(-) >>> >>> diff --git a/arch/arm64/kvm/vgic/vgic-mmio-v3.c b/arch/arm64/kvm/vgic/vgic-mmio-v3.c >>> index 581f0f490000..2f9ef6058f6e 100644 >>> --- a/arch/arm64/kvm/vgic/vgic-mmio-v3.c >>> +++ b/arch/arm64/kvm/vgic/vgic-mmio-v3.c >>> @@ -277,6 +277,8 @@ static unsigned long vgic_uaccess_read_v3r_typer(struct kvm_vcpu *vcpu, >>> gpa_t addr, unsigned int len) >>> { >>> unsigned long mpidr = kvm_vcpu_get_mpidr_aff(vcpu); >>> + struct vgic_cpu *vgic_cpu = &vcpu->arch.vgic_cpu; >>> + struct vgic_redist_region *rdreg = vgic_cpu->rdreg; >>> int target_vcpu_id = vcpu->vcpu_id; >>> u64 value; >>> >>> @@ -286,7 +288,9 @@ static unsigned long vgic_uaccess_read_v3r_typer(struct kvm_vcpu *vcpu, >>> if (vgic_has_its(vcpu->kvm)) >>> value |= GICR_TYPER_PLPIS; >>> >>> - /* reporting of the Last bit is not supported for userspace */ >>> + if (rdreg && (vgic_cpu->rdreg_index == (rdreg->free_index - 1))) >>> + value |= GICR_TYPER_LAST; >>> + >>> return extract_bytes(value, addr & 7, len); >>> } >>> >>> @@ -714,6 +718,7 @@ int vgic_register_redist_iodev(struct kvm_vcpu *vcpu) >>> return -EINVAL; >>> >>> vgic_cpu->rdreg = rdreg; >>> + vgic_cpu->rdreg_index = rdreg->free_index; >> What happens if the next redistributor region we register has the base address >> adjacent to this one? >> >> I'm really not familiar with the code, but is it not possible to create two >> Redistributor regions (via >> KVM_DEV_ARM_VGIC_GRP_ADDR(KVM_VGIC_V3_ADDR_TYPE_REDIST)) where the second >> Redistributor region start address is immediately after the last Redistributor in >> the preceding region? > KVM_VGIC_V3_ADDR_TYPE_REDIST only allows to create a single rdist > region. Only KVM_VGIC_V3_ADDR_TYPE_REDIST_REGION allows to register > several of them. > > with KVM_VGIC_V3_ADDR_TYPE_REDIST_REGION, it is possible to register > adjacent rdist regions. vgic_v3_rdist_free_slot() previously returned > the 1st rdist region where enough space remains for inserting the new > reg. We put the rdist at the free index there. > > But maybe I misunderstood your question? Yes, I think you did a good job at answering my poorly worded question. This is the case I am concerned about: 1. Userspace sets first redistributor base address to 0x0 via KVM_VGIC_V3_ADDR_TYPE_REDIST_REGION(count = 1, base = 0x0, flags = 0, index = 0). 2. Userspace sets first redistributor base address to 0x0 + 128K, immediately following the previous Redistributor. In that case the two Redistributors will be represented by two separate struct vgic_redist_region, but they are adjacent to one another and represent one contiguous memory region. From what I understand from your patch, GICR_TYPER.Last will be set for both Redistributors, when it should be set only for the second Redistributor. Does any of that make sense? Thanks, Alex > > Thanks > > Eric >> Thanks, >> Alex >>> >>> rd_base = rdreg->base + rdreg->free_index * KVM_VGIC_V3_REDIST_SIZE; >>> >>> diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h >>> index a8d8fdcd3723..596c069263a7 100644 >>> --- a/include/kvm/arm_vgic.h >>> +++ b/include/kvm/arm_vgic.h >>> @@ -322,6 +322,7 @@ struct vgic_cpu { >>> */ >>> struct vgic_io_device rd_iodev; >>> struct vgic_redist_region *rdreg; >>> + u32 rdreg_index; >>> >>> /* Contains the attributes and gpa of the LPI pending tables. */ >>> u64 pendbaser;