From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2CF86C4360F for ; Thu, 4 Apr 2019 16:43:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E38B72082E for ; Thu, 4 Apr 2019 16:43:46 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Jx4EHWjI" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729219AbfDDQnp (ORCPT ); Thu, 4 Apr 2019 12:43:45 -0400 Received: from mail-wr1-f67.google.com ([209.85.221.67]:33159 "EHLO mail-wr1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727212AbfDDQnp (ORCPT ); Thu, 4 Apr 2019 12:43:45 -0400 Received: by mail-wr1-f67.google.com with SMTP id q1so4679017wrp.0 for ; Thu, 04 Apr 2019 09:43:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2Puk8ygpZTkh3N5Vz1gIqs6zEfLw0KYa6DIW9HT9+MA=; b=Jx4EHWjIYBlIOL3wtLtHPu+uajjKfS1ahh0DV5VvdXiOBwflTxWI2P/KzN4KSGxMCC JC4+1oEJv8p6FbZ2CUjOffkWVUH+f6yk8PVCpiY8GWfNvppyONvxe4fMqFCXLbNSSOa8 CGR7TFux9Lv4zG5TULVYLlFBi5Bt0EzgN0YEn91qw7PdhCNk7mnwG1LiN/IyGi7cGIFu Ov2Kx42T0OSdHBhuNyXDcD7tXs2M6Sg//vPByQ3r5nwEhucCtWNxioc0CaZF5sWGUHfQ U+oQivxBd8TQJEobmeGhzYCVy8ZUTqh6dDnIss6s6y9gyngLKE6ECPE1Ov2x/ulBKzHg RAEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2Puk8ygpZTkh3N5Vz1gIqs6zEfLw0KYa6DIW9HT9+MA=; b=cQ1nNwnS4xlT5rhqv6WZfEU2Ah+7aELuI6/o8iHFhCQCXzl/ws1pSB+emKFd5/FNNL s27cNY6zAqngZyYwi2YRiVoaKNNKbeLw3DGpLSSE60tCVk29xeB8dpHrfVAk8nmx2IQX MvS7aPt1e9gKpucSzeo4CQYzp0IAgaxclIJJCn98jy3DVOFF4755HRPiEvFEAJeg76Cc Uq+jtbOBntTGh8sp7fS4guyBcj5dxWUIOcS8dudm34H3zb9tl5ZoaJCGYq4f3u8SzXWa x0WXj/axDQxNhR+x90zxMSH4Jhs3frvUpNl3HEfsgqMAmtRMIfIxzJbCDLsRLG6rybU7 jWRg== X-Gm-Message-State: APjAAAXcxwSxlwoYsaiPXdDpdk9v6J1KF6e93PUkoq3vqtZVErFLX+rW k0eBGVCeymo3yeuElK6utMckHOGr6F7H5tU7w7k= X-Google-Smtp-Source: APXvYqxOfmVXsO63LR9l3vlR4bZ7riDqpR9bOAdsbnqPy/021jlE8u08dQy7i3FaFl4cwDUE3NBZqNEt+RUT5C2/Jfw= X-Received: by 2002:a5d:6a8a:: with SMTP id s10mr5114136wru.66.1554396222832; Thu, 04 Apr 2019 09:43:42 -0700 (PDT) MIME-Version: 1.0 References: <1554381015-13056-1-git-send-email-yuzenghui@huawei.com> <20190404141642.385daf5b@donnerap.cambridge.arm.com> In-Reply-To: <20190404141642.385daf5b@donnerap.cambridge.arm.com> From: Zenghui Yu Date: Fri, 5 Apr 2019 00:43:29 +0800 Message-ID: Subject: Re: [PATCH] KVM: arm/arm64: vgic: Restrict setting irq->targets only in GICv2 To: Andre Przywara Cc: Zenghui Yu , suzuki.poulose@arm.com, Marc Zyngier , julien.thierry@arm.com, christoffer.dall@arm.com, LKML , eric.auger@redhat.com, james.morse@arm.com, wanghaibin.wang@huawei.com, kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Andre, Thanks for looking into this. On Thu, Apr 4, 2019 at 9:17 PM Andre Przywara wrote: > > On Thu, 4 Apr 2019 12:30:15 +0000 > Zenghui Yu wrote: > > Hi, > > > Commit ad275b8bb1e6 ("KVM: arm/arm64: vgic-new: vgic_init: implement > > vgic_init") had set irq->targets in kvm_vgic_vcpu_init(), regardless of > > the GIC architecture (v2 or v3). When the number of vcpu reaches 32 > > (in v3), UBSAN will complain about it. > > The first part looks similar to this one: > http://lists.infradead.org/pipermail/linux-arm-kernel/2019-March/637209.html Yes. I have not noticed this, sorry. > > > ================================================================================ > > UBSAN: Undefined behaviour in arch/arm64/kvm/../../../virt/kvm/arm/vgic/vgic-init.c:223:21 > > shift exponent 32 is too large for 32-bit type 'unsigned int' > > CPU: 13 PID: 833 Comm: CPU 32/KVM Kdump: loaded Not tainted 5.1.0-rc1+ #16 > > Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.58 10/24/2018 > > Call trace: > > dump_backtrace+0x0/0x190 > > show_stack+0x24/0x30 > > dump_stack+0xc8/0x114 > > ubsan_epilogue+0x14/0x50 > > __ubsan_handle_shift_out_of_bounds+0x118/0x188 > > kvm_vgic_vcpu_init+0x1d4/0x200 > > kvm_arch_vcpu_init+0x3c/0x48 > > kvm_vcpu_init+0xa8/0x100 > > kvm_arch_vcpu_create+0x94/0x120 > > kvm_vm_ioctl+0x57c/0xe58 > > do_vfs_ioctl+0xc4/0x7f0 > > ksys_ioctl+0x8c/0xa0 > > __arm64_sys_ioctl+0x28/0x38 > > el0_svc_common+0xa0/0x190 > > el0_svc_handler+0x38/0x78 > > el0_svc+0x8/0xc > > ================================================================================ > > > > This patch Restricts setting irq->targets in GICv2, which only supports > > a maximum of eight PEs, to keep UBSAN quiet. And since irq->mpidr will > > only be used by SPI in GICv3, we decided to set mpidr to 0 for SGI and > > PPI. > > > > Like commit ab2d5eb03dbb ("KVM: arm/arm64: vgic: Always initialize the > > group of private IRQs"), we should also take the creating order of the > > VGIC and VCPUs into consideration. > > > > Cc: Eric Auger > > Cc: Marc Zyngier > > Cc: Andre Przywara > > Cc: Christoffer Dall > > Signed-off-by: Zenghui Yu > > --- > > virt/kvm/arm/vgic/vgic-init.c | 16 +++++++++++----- > > 1 file changed, 11 insertions(+), 5 deletions(-) > > > > diff --git a/virt/kvm/arm/vgic/vgic-init.c b/virt/kvm/arm/vgic/vgic-init.c > > index 3bdb31e..0cba92e 100644 > > --- a/virt/kvm/arm/vgic/vgic-init.c > > +++ b/virt/kvm/arm/vgic/vgic-init.c > > @@ -220,7 +220,6 @@ int kvm_vgic_vcpu_init(struct kvm_vcpu *vcpu) > > irq->intid = i; > > irq->vcpu = NULL; > > irq->target_vcpu = vcpu; > > - irq->targets = 1U << vcpu->vcpu_id; > > kref_init(&irq->refcount); > > if (vgic_irq_is_sgi(i)) { > > /* SGIs */ > > @@ -231,10 +230,14 @@ int kvm_vgic_vcpu_init(struct kvm_vcpu *vcpu) > > irq->config = VGIC_CONFIG_LEVEL; > > } > > > > - if (dist->vgic_model == KVM_DEV_TYPE_ARM_VGIC_V3) > > + if (dist->vgic_model == KVM_DEV_TYPE_ARM_VGIC_V3) { > > irq->group = 1; > > - else > > + irq->mpidr = 0; > > + } else { > > irq->group = 0; > > + if (vcpu->vcpu_id < VGIC_V2_MAX_CPUS) > > + irq->targets = 1U << vcpu->vcpu_id; > > + } > > } > > > > if (!irqchip_in_kernel(vcpu->kvm)) > > @@ -297,10 +300,13 @@ int vgic_init(struct kvm *kvm) > > > > for (i = 0; i < VGIC_NR_PRIVATE_IRQS; i++) { > > struct vgic_irq *irq = &vgic_cpu->private_irqs[i]; > > - if (dist->vgic_model == KVM_DEV_TYPE_ARM_VGIC_V3) > > + if (dist->vgic_model == KVM_DEV_TYPE_ARM_VGIC_V3) { > > irq->group = 1; > > - else > > + irq->mpidr = 0; > > + } else { > > irq->group = 0; > > + irq->targets = 1U << vcpu->vcpu_id; > > + } > > So why would you need this part? That does the same as above, doesn't it? This idea comes from commit ab2d5eb03dbb. As Christoffer said, "we have no enforced ordering of creating the VGIC and creating VCPUs". Without this part, the VCPUs created before VGIC might still end up with the wrong "mpidr (target)" set, since they don't know the actual vGIC model. If we're using QEMU to boot a vGIC-v3 guest, we'll still find the incorrect TARGET value from debugfs. That's QEMU will create and intialize all of the VCPUs before VGIC. A detailed explanation can be found at: https://marc.info/?l=android-virt&m=154713085226516&w=2 thanks, zenghui > > Cheers, > Andre. > > > > } > > } > > > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.7 required=3.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4B830C4360F for ; Thu, 4 Apr 2019 16:43:52 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 181EE206DF for ; Thu, 4 Apr 2019 16:43:52 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="ePFeDW4I"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Jx4EHWjI" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 181EE206DF Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=wgXAxxk47oFuTAamlLwrkx1ecHsernjcwna8MoV0/Pc=; b=ePFeDW4Iz2otPf dUTwnXeQ4EdFiORfzclScys9S8YYjwy7WZWGjnTuaOEkwf2hChaD6kvBtPI8U0UP5V46oXMxDJpKQ Ywizpw87GXpkokdwTDVVDN1CpFSJRRplScm7RJ7fn80po8jmUen9A/Hcbx5NjauTJ+2bZU6rvXtOm rcThtQ+Kq1gif03NdeFVHibDHinpPhO2icKUJd6m46GnCI+8tV1KybgPn9yO0k5mCXFhUiWrMSMBy ae8l+/CLMLcfjZGsfaCSq9cx926G+pr8ua8dUjKr1Z1K6DNh7DnqucZJ0lVwXg4RkMiRU/ae1eDEH 16OzAdyFL7517ugpDV+w==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1hC5Su-00070J-Kf; Thu, 04 Apr 2019 16:43:48 +0000 Received: from mail-wr1-x444.google.com ([2a00:1450:4864:20::444]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1hC5Sr-0006zt-0B for linux-arm-kernel@lists.infradead.org; Thu, 04 Apr 2019 16:43:46 +0000 Received: by mail-wr1-x444.google.com with SMTP id s15so4593329wra.12 for ; Thu, 04 Apr 2019 09:43:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2Puk8ygpZTkh3N5Vz1gIqs6zEfLw0KYa6DIW9HT9+MA=; b=Jx4EHWjIYBlIOL3wtLtHPu+uajjKfS1ahh0DV5VvdXiOBwflTxWI2P/KzN4KSGxMCC JC4+1oEJv8p6FbZ2CUjOffkWVUH+f6yk8PVCpiY8GWfNvppyONvxe4fMqFCXLbNSSOa8 CGR7TFux9Lv4zG5TULVYLlFBi5Bt0EzgN0YEn91qw7PdhCNk7mnwG1LiN/IyGi7cGIFu Ov2Kx42T0OSdHBhuNyXDcD7tXs2M6Sg//vPByQ3r5nwEhucCtWNxioc0CaZF5sWGUHfQ U+oQivxBd8TQJEobmeGhzYCVy8ZUTqh6dDnIss6s6y9gyngLKE6ECPE1Ov2x/ulBKzHg RAEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2Puk8ygpZTkh3N5Vz1gIqs6zEfLw0KYa6DIW9HT9+MA=; b=ZvAaZPhCqykK4iRAy/H0pY0BBtVbUk8LpSmuiDRqK1VhRTWd50EgCQCsV1r1D1YY9w L0vbM1TnzXQGI9Ez7NBr7s8UunEU7nfVU6MV5pPNKJ3YL09iIiWTwL3m+3Mo2EPSCvbj 0CcKlxInXzA97kj+w6YWrtokLgFvIilb6F63uYenGDsnr50EGCl4a3Xkdn8euf9lcnbP 8dXDzZ3KGuxhXeFqQR54dC4VAjb3xR/No1UicYS0fKjkx55daTfw4iAk2G1Vcy/RDU0Y L4xnu+bGdC+ANCEmSsZvEZTVuxzvMVbnyZyvkP0XvF3C8be5FyS/ZXBEtIxJpcBTKkiV rnMg== X-Gm-Message-State: APjAAAV1wujDLANEwi5Sf5YpZAl/7xoh3i29c7oMGYa9EucfiESII3nx GZRzOoR7gTyfYjb1UoMpc6mYa5vNpdS96pgFTdw= X-Google-Smtp-Source: APXvYqxOfmVXsO63LR9l3vlR4bZ7riDqpR9bOAdsbnqPy/021jlE8u08dQy7i3FaFl4cwDUE3NBZqNEt+RUT5C2/Jfw= X-Received: by 2002:a5d:6a8a:: with SMTP id s10mr5114136wru.66.1554396222832; Thu, 04 Apr 2019 09:43:42 -0700 (PDT) MIME-Version: 1.0 References: <1554381015-13056-1-git-send-email-yuzenghui@huawei.com> <20190404141642.385daf5b@donnerap.cambridge.arm.com> In-Reply-To: <20190404141642.385daf5b@donnerap.cambridge.arm.com> From: Zenghui Yu Date: Fri, 5 Apr 2019 00:43:29 +0800 Message-ID: Subject: Re: [PATCH] KVM: arm/arm64: vgic: Restrict setting irq->targets only in GICv2 To: Andre Przywara X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190404_094345_272517_0FC2940C X-CRM114-Status: GOOD ( 24.16 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: julien.thierry@arm.com, Marc Zyngier , suzuki.poulose@arm.com, christoffer.dall@arm.com, LKML , eric.auger@redhat.com, james.morse@arm.com, Zenghui Yu , wanghaibin.wang@huawei.com, kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Andre, Thanks for looking into this. On Thu, Apr 4, 2019 at 9:17 PM Andre Przywara wrote: > > On Thu, 4 Apr 2019 12:30:15 +0000 > Zenghui Yu wrote: > > Hi, > > > Commit ad275b8bb1e6 ("KVM: arm/arm64: vgic-new: vgic_init: implement > > vgic_init") had set irq->targets in kvm_vgic_vcpu_init(), regardless of > > the GIC architecture (v2 or v3). When the number of vcpu reaches 32 > > (in v3), UBSAN will complain about it. > > The first part looks similar to this one: > http://lists.infradead.org/pipermail/linux-arm-kernel/2019-March/637209.html Yes. I have not noticed this, sorry. > > > ================================================================================ > > UBSAN: Undefined behaviour in arch/arm64/kvm/../../../virt/kvm/arm/vgic/vgic-init.c:223:21 > > shift exponent 32 is too large for 32-bit type 'unsigned int' > > CPU: 13 PID: 833 Comm: CPU 32/KVM Kdump: loaded Not tainted 5.1.0-rc1+ #16 > > Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.58 10/24/2018 > > Call trace: > > dump_backtrace+0x0/0x190 > > show_stack+0x24/0x30 > > dump_stack+0xc8/0x114 > > ubsan_epilogue+0x14/0x50 > > __ubsan_handle_shift_out_of_bounds+0x118/0x188 > > kvm_vgic_vcpu_init+0x1d4/0x200 > > kvm_arch_vcpu_init+0x3c/0x48 > > kvm_vcpu_init+0xa8/0x100 > > kvm_arch_vcpu_create+0x94/0x120 > > kvm_vm_ioctl+0x57c/0xe58 > > do_vfs_ioctl+0xc4/0x7f0 > > ksys_ioctl+0x8c/0xa0 > > __arm64_sys_ioctl+0x28/0x38 > > el0_svc_common+0xa0/0x190 > > el0_svc_handler+0x38/0x78 > > el0_svc+0x8/0xc > > ================================================================================ > > > > This patch Restricts setting irq->targets in GICv2, which only supports > > a maximum of eight PEs, to keep UBSAN quiet. And since irq->mpidr will > > only be used by SPI in GICv3, we decided to set mpidr to 0 for SGI and > > PPI. > > > > Like commit ab2d5eb03dbb ("KVM: arm/arm64: vgic: Always initialize the > > group of private IRQs"), we should also take the creating order of the > > VGIC and VCPUs into consideration. > > > > Cc: Eric Auger > > Cc: Marc Zyngier > > Cc: Andre Przywara > > Cc: Christoffer Dall > > Signed-off-by: Zenghui Yu > > --- > > virt/kvm/arm/vgic/vgic-init.c | 16 +++++++++++----- > > 1 file changed, 11 insertions(+), 5 deletions(-) > > > > diff --git a/virt/kvm/arm/vgic/vgic-init.c b/virt/kvm/arm/vgic/vgic-init.c > > index 3bdb31e..0cba92e 100644 > > --- a/virt/kvm/arm/vgic/vgic-init.c > > +++ b/virt/kvm/arm/vgic/vgic-init.c > > @@ -220,7 +220,6 @@ int kvm_vgic_vcpu_init(struct kvm_vcpu *vcpu) > > irq->intid = i; > > irq->vcpu = NULL; > > irq->target_vcpu = vcpu; > > - irq->targets = 1U << vcpu->vcpu_id; > > kref_init(&irq->refcount); > > if (vgic_irq_is_sgi(i)) { > > /* SGIs */ > > @@ -231,10 +230,14 @@ int kvm_vgic_vcpu_init(struct kvm_vcpu *vcpu) > > irq->config = VGIC_CONFIG_LEVEL; > > } > > > > - if (dist->vgic_model == KVM_DEV_TYPE_ARM_VGIC_V3) > > + if (dist->vgic_model == KVM_DEV_TYPE_ARM_VGIC_V3) { > > irq->group = 1; > > - else > > + irq->mpidr = 0; > > + } else { > > irq->group = 0; > > + if (vcpu->vcpu_id < VGIC_V2_MAX_CPUS) > > + irq->targets = 1U << vcpu->vcpu_id; > > + } > > } > > > > if (!irqchip_in_kernel(vcpu->kvm)) > > @@ -297,10 +300,13 @@ int vgic_init(struct kvm *kvm) > > > > for (i = 0; i < VGIC_NR_PRIVATE_IRQS; i++) { > > struct vgic_irq *irq = &vgic_cpu->private_irqs[i]; > > - if (dist->vgic_model == KVM_DEV_TYPE_ARM_VGIC_V3) > > + if (dist->vgic_model == KVM_DEV_TYPE_ARM_VGIC_V3) { > > irq->group = 1; > > - else > > + irq->mpidr = 0; > > + } else { > > irq->group = 0; > > + irq->targets = 1U << vcpu->vcpu_id; > > + } > > So why would you need this part? That does the same as above, doesn't it? This idea comes from commit ab2d5eb03dbb. As Christoffer said, "we have no enforced ordering of creating the VGIC and creating VCPUs". Without this part, the VCPUs created before VGIC might still end up with the wrong "mpidr (target)" set, since they don't know the actual vGIC model. If we're using QEMU to boot a vGIC-v3 guest, we'll still find the incorrect TARGET value from debugfs. That's QEMU will create and intialize all of the VCPUs before VGIC. A detailed explanation can be found at: https://marc.info/?l=android-virt&m=154713085226516&w=2 thanks, zenghui > > Cheers, > Andre. > > > > } > > } > > > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel