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 lists.gnu.org (lists.gnu.org [209.51.188.17]) (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 144EBC43334 for ; Tue, 26 Jul 2022 07:57:26 +0000 (UTC) Received: from localhost ([::1]:43118 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oGFRV-00075k-Nn for qemu-devel@archiver.kernel.org; Tue, 26 Jul 2022 03:57:25 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:43066) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oGFPu-0006Dr-At for qemu-devel@nongnu.org; Tue, 26 Jul 2022 03:55:46 -0400 Received: from smtp21.cstnet.cn ([159.226.251.21]:36772 helo=cstnet.cn) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oGFPr-0001KA-81 for qemu-devel@nongnu.org; Tue, 26 Jul 2022 03:55:46 -0400 Received: from smtpclient.apple (unknown [159.226.43.13]) by APP-01 (Coremail) with SMTP id qwCowACHaVrynd9ifIt5Ag--.37610S2; Tue, 26 Jul 2022 15:55:31 +0800 (CST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: [PATCH v4] hw/nvme: Use ioeventfd to handle doorbell updates From: Jinhao Fan In-Reply-To: Date: Tue, 26 Jul 2022 15:55:30 +0800 Cc: qemu-devel@nongnu.org, kbusch@kernel.org Content-Transfer-Encoding: quoted-printable Message-Id: <869047CA-DD0A-45D1-9DBA-2BA1A3E00ADF@ict.ac.cn> References: <20220705142403.101539-1-fanjinhao21s@ict.ac.cn> To: Klaus Jensen X-Mailer: Apple Mail (2.3654.120.0.1.13) X-CM-TRANSID: qwCowACHaVrynd9ifIt5Ag--.37610S2 X-Coremail-Antispam: 1UD129KBjvdXoW7Gw4xXF4xJr4fZrWrXw15CFg_yoWfArX_ur 109r1DCw48JryjkrWDGFn8ZFn7ta98Xry5Xr1DXw18ua45Xr9xCFsYgFnavw17Ars2qry3 CwnrtFsI9F909jkaLaAFLSUrUUUUUb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUb2xYjsxI4VWkCwAYFVCjjxCrM7AC8VAFwI0_Jr0_Gr1l1xkIjI8I 6I8E6xAIw20EY4v20xvaj40_Wr0E3s1l1IIY67AEw4v_Jr0_Jr4l8cAvFVAK0II2c7xJM2 8CjxkF64kEwVA0rcxSw2x7M28EF7xvwVC0I7IYx2IY67AKxVW8JVW5JwA2z4x0Y4vE2Ix0 cI8IcVCY1x0267AKxVW8JVWxJwA2z4x0Y4vEx4A2jsIE14v26F4UJVW0owA2z4x0Y4vEx4 A2jsIEc7CjxVAFwI0_Cr1j6rxdM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI 64kE6c02F40Ex7xfMcIj6xIIjxv20xvE14v26r106r15McIj6I8E87Iv67AKxVWUJVW8Jw Am72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IYc2Ij64vIr41lc2xSY4AK67AK6r4xMxAIw28I cxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_Jr0_Jr4lx2 IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUXVWUAwCIc40Y0x0EwIxGrwCI 42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwCI42 IY6xAIw20EY4v20xvaj40_Wr1j6rW3Jr1lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2 z280aVCY1x0267AKxVWUJVW8JbIYCTnIWIevJa73UjIFyTuYvjxU2NeODUUUU X-Originating-IP: [159.226.43.13] X-CM-SenderInfo: xidqyxpqkd0j0rv6xunwoduhdfq/ Received-SPF: pass client-ip=159.226.251.21; envelope-from=fanjinhao21s@ict.ac.cn; helo=cstnet.cn X-Spam_score_int: -41 X-Spam_score: -4.2 X-Spam_bar: ---- X-Spam_report: (-4.2 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" at 3:41 PM, Klaus Jensen wrote: > On Jul 26 15:35, Jinhao Fan wrote: >> at 4:55 AM, Klaus Jensen wrote: >>=20 >>> We have a regression following this patch that we need to address. >>>=20 >>> With this patch, issuing a reset on the device (`nvme reset = /dev/nvme0` >>> will do the trick) causes QEMU to hog my host cpu at 100%. >>>=20 >>> I'm still not sure what causes this. The trace output is a bit >>> inconclusive still. >>>=20 >>> I'll keep looking into it. >>=20 >> I cannot reproduce this bug. I just start the VM and used `nvme reset >> /dev/nvme0`. Did you do anything before the reset? >=20 > Interesting and thanks for checking! Looks like a kernel issue then! >=20 > I remember that I'm using a dev branch (nvme-v5.20) of the kernel and > reverting to a stock OS kernel did not produce the bug. I=E2=80=99m using 5.19-rc4 which I pulled from linux-next on Jul 1. It = works ok on my machine.=