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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id AA0C5C77B7A for ; Wed, 24 May 2023 12:41:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=pcAt1pWeEstJYbeCj9cCtId+2eibVH/V4IqijTqQYdM=; b=u7rfmuXz/SVVKC xqItBXWNmtnYPIH/1ZGedpe8N1aDadJRHfv58HyXvJia6ANq0I/6sr3qCN1F/nSFf423/SjzsAu7G Cb5JRYIt89b/JNjHuP9pgYJEyHZLfNuEn9gHla12vely/83h/+2aqKmjQUCssCuYBG6k7jvLCU/Zt s+Vp6I9IbbJLEURh4xqfIGmUqkC4wbSmKnMeFWZ0BP4OYaqQ6o7GOD2ULg1lJU2TyYClzNKZJTHR/ 6xUuYDaqCk+74Mqged3VeY/jfSBLmpsI/KWm2acCjjuj9izkuJ3CgqiqKwI3dhdOBElV+bHSpl6X3 5gFhkjsKkpAvJ2n2mNmw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1q1nnK-00DSG2-2L; Wed, 24 May 2023 12:40:46 +0000 Received: from mail-wr1-x435.google.com ([2a00:1450:4864:20::435]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1q1nnH-00DSEp-27 for linux-arm-kernel@lists.infradead.org; Wed, 24 May 2023 12:40:45 +0000 Received: by mail-wr1-x435.google.com with SMTP id ffacd0b85a97d-3063433fa66so535103f8f.3 for ; Wed, 24 May 2023 05:40:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1684932041; x=1687524041; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=bNqHVjiAPgcoX4AAtv5Chj9IfcChBtd2gbcHB24g+D4=; b=HnXXezDYG17WebHzWaeBvSzjE6X5zZ93pBJRnP1uus8Z47y5c4ecwWgXRFimW2mvIm Rbi4sRvb6Gq0HpItiOOaOkKxnGok7GAvz4VlWya9wKiv+yJsCvetAhkaLCRaW6MpipQc duoL79rzF23C90aeofuyMUj0FrHjYIGyeSljHuUgxwJ4tg/FQ9jG0J8mu5Ql7GIWTx4N dH2jyl9J7Aceg6afbTsYDhVnpebnDqi9N/XCkkOUCMahiE7msN0rA0vaGHYfl1VDy06X Q2hR90Q6znvXMQtcNjnqmog2rfKhFFkuvXP2C+kjDIU/Mhp4Y0IYizjD1JpNgS73M/I5 knrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684932041; x=1687524041; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=bNqHVjiAPgcoX4AAtv5Chj9IfcChBtd2gbcHB24g+D4=; b=OcOlx5iLq0rpHzXBbwgKuJUxLUniTh0n/8VOJxyTHESRZ7tTxInFds8v2fycYjIvEz If1NM+eH31M3o982XBoFQjzerkN2Q3XzqqfI0hb1tRf1eyN9L0rRGGXrCvRKIcW81eZH iNe+0KBmarjBPJod3sJ23MNDMOxbPBDUR1wNIl6sf4hOj3WQkBEPYgE4vxa91qd78TgG EDCQLaTaZlsbYJbQC1A5dpjT4eGlGvecbhK5jfpExOdnvQ1jgxoWpgkXLalLQpMXftu2 +hYw92ouzxPS0XzDmAkHNOpMtzajW5x4ulnCGLuimBVD3xEq+Ni3GZTqSZ+zQ8gt7NxZ uAXw== X-Gm-Message-State: AC+VfDwUwBPOaFOv4nThFJJh2hTXJNDmC/1w0MJ3iyyVcYIUhXBKE0wt SQ0YZfE9aovGeJt0tTSkq1KOAg== X-Google-Smtp-Source: ACHHUZ7nIrqPldKdUyRyL1Ju/ax0rCU5vJ28/C0/Xl8RckP1R2RBfphk946YNTbndFjLzoFRPtUylg== X-Received: by 2002:adf:f342:0:b0:306:30ea:a072 with SMTP id e2-20020adff342000000b0030630eaa072mr11215655wrp.53.1684932040673; Wed, 24 May 2023 05:40:40 -0700 (PDT) Received: from myrica (5750a5b3.skybroadband.com. [87.80.165.179]) by smtp.gmail.com with ESMTPSA id l3-20020a1ced03000000b003f4ddde398csm2303897wmh.21.2023.05.24.05.40.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 May 2023 05:40:39 -0700 (PDT) Date: Wed, 24 May 2023 13:40:42 +0100 From: Jean-Philippe Brucker To: Marc Zyngier Cc: oliver.upton@linux.dev, james.morse@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, catalin.marinas@arm.com, will@kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev Subject: Re: [PATCH 0/4] KVM: arm64: vgic: Locking fixes Message-ID: <20230524124042.GA48723@myrica> References: <20230518100914.2837292-1-jean-philippe@linaro.org> <86cz2wlnd6.wl-maz@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <86cz2wlnd6.wl-maz@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230524_054043_695395_A9BC6AE6 X-CRM114-Status: GOOD ( 27.45 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, May 19, 2023 at 09:46:45AM +0100, Marc Zyngier wrote: > On Thu, 18 May 2023 11:09:14 +0100, > Jean-Philippe Brucker wrote: > > > > Another fun locking puzzle, between the new config_lock and srcu. > > Patch 1 attempts to fix it, and the other patches fix simpler issues. > > Thanks for that and for your excellent description of the problems. > > > I got these lockdep reports while running KVM QEMU on a TCG QEMU, but it > > can also be triggered by running the vgic_irq kselftest on TCG QEMU. > > Now, with the fix and lockdep enabled, vgic_irq hangs but I believe it's > > an unrelated weirdness: if I introduce a separate lockdep warning for > > some made up locks, then the test passes again. So I'm sending this out > > now for discussion, and will investigate that one later. > > I've taken these patches for a spin, and I cannot reproduce this hang, > though I'm running on actual HW and not QEMU. It would be really > annoying if lockdep actively introduced issues... :-/ > > Any chance you could dig into this as you have a good reproducer? I'll > try to setup a TGC environment on my end as well. I'm not sure this is a fixable problem, didn't find anything obviously wrong. It's just that when running with lockdep and KASAN (forgot about that one, sorry) on an emulated platform, some tests can't make progress. In this config I can boot a guest without problem, but this particular test gets stuck when trying to inject 32 interrupts. What I see is: 1. KVM prepares to enter the guest, spends a lot of time dealing with the vGIC with interrupts disabled. 2. Just before entering the guest it sees ISR_EL1 set (the timer interrupt is pending), so cancels the return to guest, reprograms the timer and goto 1. For this particular test, trying to inject several interrupts simultaneously, I think kvm_vgic_flush_hwstate() needs to take and release lots of locks which takes forever with lockdep. I measure about 4ms inside that function, which corresponds to the timer period at HZ_250. Previously, I guess getting a lockdep warning would disable lockdep and allow the test to make progress. So maybe the vGIC could still be optimized, or maybe this isn't worth fixing, we could just say that this setup is too slow to reliably run KVM and leave it at that. Thanks, Jean _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel