From mboxrd@z Thu Jan 1 00:00:00 1970 Received: by 2002:a17:906:6a09:b0:a6f:1bf6:7fc1 with SMTP id qw9csp281304ejc; Wed, 12 Jun 2024 02:54:25 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCVdHTgpo1LQ4efYFCbgG2xYG7nyGugjg7av/gmsQm6+FRKNnXNvAq4Zayczmfz6YrOWTzKMjw3YLP7RbQVWRRdeFrRi/s6V X-Google-Smtp-Source: AGHT+IHm/tXJwftiQM4IVFcWhoSxj7CqgMESIpMfLu++PmyK88KwMz1eKwENUeuSO0RXBO+MkKVq X-Received: by 2002:ac8:5f47:0:b0:43a:bee9:ebc with SMTP id d75a77b69052e-44159afe813mr21531711cf.19.1718186065160; Wed, 12 Jun 2024 02:54:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1718186065; cv=none; d=google.com; s=arc-20160816; b=vReQSfJTLjAVNbSbW70fxdhzy6tcsTFvqABSecMHZY8nV/rQlmnTilPcTJtxwYrNeY 2z1g4KgqK9WXuiKvUQHn4fvmHeYs49zWEIL9MNF01gQl0V6AM/UgBx1FhUK6/nrzVLLt jsftA4ZK6bOE6NjdEFYRreeIWqF9Pck/7nfjEejawIhByB/40nB5WTJCqXyQtB3s3lo1 N5ERLufxcacwJJ6j+WPCjbyRCnwbEtgOCdeQSVJbDaltOkhDYcIrSBKV/sxXQ8gr6l9/ dcMA0cn7uc5XvweExIWR7rTwmyxAtfv5ZbuZKp5PurbNwXNZLTWJhrx9OUfGgPbIPel9 TyXg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=sender:errors-to:from:reply-to:list-subscribe:list-help:list-post :list-archive:list-unsubscribe:list-id:precedence :content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:date; bh=gLMRpnKDKadwF/tUh2nZ+vLurezt77BKmiLqiwkS/yg=; fh=pvtddvpBttEhgFAmD4FZqkRYXIsnyN0iFSsYRxfWif4=; b=uKrE699kQSe6LkPPeOA0YZ4tVLV1i0xCC5Ij0CFbfL+o8hApuaj/FQQEIdpeiVmvbu hwccEI2vGp0Ub57zmgYoZ3w+97wd75XQo7cIYOK77P9RCpAyP7eAky76NLqbZwXzvGFd UT2rRTDgQe2N8FB32udVhM/4PwHv7rjgB+7/7+DPUgJSJ4/5nVzSAKO/XHzwp/YxRyLi X7BCIkwVGU77thPM8edYT+wEdVIeUeUsuND7u+aeRJzHkFCeW6CMeUGCY6uYU3mLMpJB jAxgtTwGpjHCacFe92If1w7nf9nuw8LiVt9jxKh35bCWyx70LYS7u2j0XSwNBZyT7pw5 JW7g==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of qemu-arm-bounces+alex.bennee=linaro.org@nongnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom="qemu-arm-bounces+alex.bennee=linaro.org@nongnu.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=nongnu.org Return-Path: Received: from lists.gnu.org (lists.gnu.org. [209.51.188.17]) by mx.google.com with ESMTPS id d75a77b69052e-44038b3c2bdsi153365961cf.467.2024.06.12.02.54.23 for (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Wed, 12 Jun 2024 02:54:25 -0700 (PDT) Received-SPF: pass (google.com: domain of qemu-arm-bounces+alex.bennee=linaro.org@nongnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; Authentication-Results: mx.google.com; spf=pass (google.com: domain of qemu-arm-bounces+alex.bennee=linaro.org@nongnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom="qemu-arm-bounces+alex.bennee=linaro.org@nongnu.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=nongnu.org Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sHKg1-0001k2-CK; Wed, 12 Jun 2024 05:53:57 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sHKfz-0001jI-CK; Wed, 12 Jun 2024 05:53:55 -0400 Received: from frasgout.his.huawei.com ([185.176.79.56]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sHKfw-0007JR-Tu; Wed, 12 Jun 2024 05:53:55 -0400 Received: from mail.maildlp.com (unknown [172.18.186.216]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4VzgnD6BDKz6K8xl; Wed, 12 Jun 2024 17:52:16 +0800 (CST) Received: from lhrpeml500005.china.huawei.com (unknown [7.191.163.240]) by mail.maildlp.com (Postfix) with ESMTPS id 084BC140B2F; Wed, 12 Jun 2024 17:53:38 +0800 (CST) Received: from localhost (10.202.227.76) by lhrpeml500005.china.huawei.com (7.191.163.240) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Wed, 12 Jun 2024 10:53:30 +0100 Date: Wed, 12 Jun 2024 10:53:29 +0100 To: Zhenyu Zhang CC: , , , , , , , , , Subject: Re: [PATCH v3] hw/arm/virt: Avoid unexpected warning from Linux guest on host with Fujitsu CPUs Message-ID: <20240612105329.00004607@Huawei.com> In-Reply-To: <20240612020506.307793-1-zhenyzha@redhat.com> References: <20240612020506.307793-1-zhenyzha@redhat.com> Organization: Huawei Technologies Research and Development (UK) Ltd. X-Mailer: Claws Mail 4.1.0 (GTK 3.24.33; x86_64-w64-mingw32) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.202.227.76] X-ClientProxiedBy: lhrpeml100006.china.huawei.com (7.191.160.224) To lhrpeml500005.china.huawei.com (7.191.163.240) Received-SPF: pass client-ip=185.176.79.56; envelope-from=jonathan.cameron@huawei.com; helo=frasgout.his.huawei.com 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=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-arm@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-to: Jonathan Cameron From: Jonathan Cameron via Errors-To: qemu-arm-bounces+alex.bennee=linaro.org@nongnu.org Sender: qemu-arm-bounces+alex.bennee=linaro.org@nongnu.org X-TUID: W5553bsB0hR+ On Tue, 11 Jun 2024 22:05:06 -0400 Zhenyu Zhang wrote: > Multiple warning messages and corresponding backtraces are observed when Linux > guest is booted on the host with Fujitsu CPUs. One of them is shown as below. > > [ 0.032443] ------------[ cut here ]------------ > [ 0.032446] uart-pl011 9000000.pl011: ARCH_DMA_MINALIGN smaller than > CTR_EL0.CWG (128 < 256) > [ 0.032454] WARNING: CPU: 0 PID: 1 at arch/arm64/mm/dma-mapping.c:54 > arch_setup_dma_ops+0xbc/0xcc > [ 0.032470] Modules linked in: > [ 0.032475] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.14.0-452.el9.aarch64 > [ 0.032481] Hardware name: linux,dummy-virt (DT) > [ 0.032484] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) > [ 0.032490] pc : arch_setup_dma_ops+0xbc/0xcc > [ 0.032496] lr : arch_setup_dma_ops+0xbc/0xcc > [ 0.032501] sp : ffff80008003b860 > [ 0.032503] x29: ffff80008003b860 x28: 0000000000000000 x27: ffffaae4b949049c > [ 0.032510] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 > [ 0.032517] x23: 0000000000000100 x22: 0000000000000000 x21: 0000000000000000 > [ 0.032523] x20: 0000000100000000 x19: ffff2f06c02ea400 x18: ffffffffffffffff > [ 0.032529] x17: 00000000208a5f76 x16: 000000006589dbcb x15: ffffaae4ba071c89 > [ 0.032535] x14: 0000000000000000 x13: ffffaae4ba071c84 x12: 455f525443206e61 > [ 0.032541] x11: 68742072656c6c61 x10: 0000000000000029 x9 : ffffaae4b7d21da4 > [ 0.032547] x8 : 0000000000000029 x7 : 4c414e494d5f414d x6 : 0000000000000029 > [ 0.032553] x5 : 000000000000000f x4 : ffffaae4b9617a00 x3 : 0000000000000001 > [ 0.032558] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff2f06c029be40 > [ 0.032564] Call trace: > [ 0.032566] arch_setup_dma_ops+0xbc/0xcc > [ 0.032572] of_dma_configure_id+0x138/0x300 > [ 0.032591] amba_dma_configure+0x34/0xc0 > [ 0.032600] really_probe+0x78/0x3dc > [ 0.032614] __driver_probe_device+0x108/0x160 > [ 0.032619] driver_probe_device+0x44/0x114 > [ 0.032624] __device_attach_driver+0xb8/0x14c > [ 0.032629] bus_for_each_drv+0x88/0xe4 > [ 0.032634] __device_attach+0xb0/0x1e0 > [ 0.032638] device_initial_probe+0x18/0x20 > [ 0.032643] bus_probe_device+0xa8/0xb0 > [ 0.032648] device_add+0x4b4/0x6c0 > [ 0.032652] amba_device_try_add.part.0+0x48/0x360 > [ 0.032657] amba_device_add+0x104/0x144 > [ 0.032662] of_amba_device_create.isra.0+0x100/0x1c4 > [ 0.032666] of_platform_bus_create+0x294/0x35c > [ 0.032669] of_platform_populate+0x5c/0x150 > [ 0.032672] of_platform_default_populate_init+0xd0/0xec > [ 0.032697] do_one_initcall+0x4c/0x2e0 > [ 0.032701] do_initcalls+0x100/0x13c > [ 0.032707] kernel_init_freeable+0x1c8/0x21c > [ 0.032712] kernel_init+0x28/0x140 > [ 0.032731] ret_from_fork+0x10/0x20 > [ 0.032735] ---[ end trace 0000000000000000 ]--- > > In Linux, a check is applied to every device which is exposed through > device-tree node. The warning message is raised when the device isn't > DMA coherent and the cache line size is larger than ARCH_DMA_MINALIGN > (128 bytes). The cache line is sorted from CTR_EL0[CWG], which corresponds > to 256 bytes on the guest CPUs. The DMA coherent capability is claimed > through 'dma-coherent' in their device-tree nodes or parent nodes. > > Fix the issue by adding 'dma-coherent' property to the device-tree root > node, meaning all devices are capable of DMA coherent by default. > > Signed-off-by: Zhenyu Zhang Aligns with earlier discussion so... Reviewed-by: Jonathan Cameron > --- > v3: Add comments explaining why we add 'dma-coherent' property (Peter) > --- > hw/arm/virt.c | 11 +++++++++++ > 1 file changed, 11 insertions(+) > > diff --git a/hw/arm/virt.c b/hw/arm/virt.c > index 3c93c0c0a6..3cefac6d43 100644 > --- a/hw/arm/virt.c > +++ b/hw/arm/virt.c > @@ -271,6 +271,17 @@ static void create_fdt(VirtMachineState *vms) > qemu_fdt_setprop_cell(fdt, "/", "#size-cells", 0x2); > qemu_fdt_setprop_string(fdt, "/", "model", "linux,dummy-virt"); > > + /* > + * For QEMU, all DMA is coherent. Advertising this in the root node > + * has two benefits: > + * > + * - It avoids potential bugs where we forget to mark a DMA > + * capable device as being dma-coherent > + * - It avoids spurious warnings from the Linux kernel about > + * devices which can't do DMA at all > + */ > + qemu_fdt_setprop(fdt, "/", "dma-coherent", NULL, 0); > + > /* /chosen must exist for load_dtb to fill in necessary properties later */ > qemu_fdt_add_subnode(fdt, "/chosen"); > if (vms->dtb_randomness) { 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 9D2B5C27C77 for ; Wed, 12 Jun 2024 09:54:31 +0000 (UTC) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sHKg2-0001kK-At; Wed, 12 Jun 2024 05:53:58 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sHKfz-0001jI-CK; Wed, 12 Jun 2024 05:53:55 -0400 Received: from frasgout.his.huawei.com ([185.176.79.56]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sHKfw-0007JR-Tu; Wed, 12 Jun 2024 05:53:55 -0400 Received: from mail.maildlp.com (unknown [172.18.186.216]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4VzgnD6BDKz6K8xl; Wed, 12 Jun 2024 17:52:16 +0800 (CST) Received: from lhrpeml500005.china.huawei.com (unknown [7.191.163.240]) by mail.maildlp.com (Postfix) with ESMTPS id 084BC140B2F; Wed, 12 Jun 2024 17:53:38 +0800 (CST) Received: from localhost (10.202.227.76) by lhrpeml500005.china.huawei.com (7.191.163.240) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Wed, 12 Jun 2024 10:53:30 +0100 Date: Wed, 12 Jun 2024 10:53:29 +0100 To: Zhenyu Zhang CC: , , , , , , , , , Subject: Re: [PATCH v3] hw/arm/virt: Avoid unexpected warning from Linux guest on host with Fujitsu CPUs Message-ID: <20240612105329.00004607@Huawei.com> In-Reply-To: <20240612020506.307793-1-zhenyzha@redhat.com> References: <20240612020506.307793-1-zhenyzha@redhat.com> Organization: Huawei Technologies Research and Development (UK) Ltd. X-Mailer: Claws Mail 4.1.0 (GTK 3.24.33; x86_64-w64-mingw32) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.202.227.76] X-ClientProxiedBy: lhrpeml100006.china.huawei.com (7.191.160.224) To lhrpeml500005.china.huawei.com (7.191.163.240) Received-SPF: pass client-ip=185.176.79.56; envelope-from=jonathan.cameron@huawei.com; helo=frasgout.his.huawei.com 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=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: , Reply-to: Jonathan Cameron From: Jonathan Cameron via Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org On Tue, 11 Jun 2024 22:05:06 -0400 Zhenyu Zhang wrote: > Multiple warning messages and corresponding backtraces are observed when Linux > guest is booted on the host with Fujitsu CPUs. One of them is shown as below. > > [ 0.032443] ------------[ cut here ]------------ > [ 0.032446] uart-pl011 9000000.pl011: ARCH_DMA_MINALIGN smaller than > CTR_EL0.CWG (128 < 256) > [ 0.032454] WARNING: CPU: 0 PID: 1 at arch/arm64/mm/dma-mapping.c:54 > arch_setup_dma_ops+0xbc/0xcc > [ 0.032470] Modules linked in: > [ 0.032475] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.14.0-452.el9.aarch64 > [ 0.032481] Hardware name: linux,dummy-virt (DT) > [ 0.032484] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) > [ 0.032490] pc : arch_setup_dma_ops+0xbc/0xcc > [ 0.032496] lr : arch_setup_dma_ops+0xbc/0xcc > [ 0.032501] sp : ffff80008003b860 > [ 0.032503] x29: ffff80008003b860 x28: 0000000000000000 x27: ffffaae4b949049c > [ 0.032510] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 > [ 0.032517] x23: 0000000000000100 x22: 0000000000000000 x21: 0000000000000000 > [ 0.032523] x20: 0000000100000000 x19: ffff2f06c02ea400 x18: ffffffffffffffff > [ 0.032529] x17: 00000000208a5f76 x16: 000000006589dbcb x15: ffffaae4ba071c89 > [ 0.032535] x14: 0000000000000000 x13: ffffaae4ba071c84 x12: 455f525443206e61 > [ 0.032541] x11: 68742072656c6c61 x10: 0000000000000029 x9 : ffffaae4b7d21da4 > [ 0.032547] x8 : 0000000000000029 x7 : 4c414e494d5f414d x6 : 0000000000000029 > [ 0.032553] x5 : 000000000000000f x4 : ffffaae4b9617a00 x3 : 0000000000000001 > [ 0.032558] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff2f06c029be40 > [ 0.032564] Call trace: > [ 0.032566] arch_setup_dma_ops+0xbc/0xcc > [ 0.032572] of_dma_configure_id+0x138/0x300 > [ 0.032591] amba_dma_configure+0x34/0xc0 > [ 0.032600] really_probe+0x78/0x3dc > [ 0.032614] __driver_probe_device+0x108/0x160 > [ 0.032619] driver_probe_device+0x44/0x114 > [ 0.032624] __device_attach_driver+0xb8/0x14c > [ 0.032629] bus_for_each_drv+0x88/0xe4 > [ 0.032634] __device_attach+0xb0/0x1e0 > [ 0.032638] device_initial_probe+0x18/0x20 > [ 0.032643] bus_probe_device+0xa8/0xb0 > [ 0.032648] device_add+0x4b4/0x6c0 > [ 0.032652] amba_device_try_add.part.0+0x48/0x360 > [ 0.032657] amba_device_add+0x104/0x144 > [ 0.032662] of_amba_device_create.isra.0+0x100/0x1c4 > [ 0.032666] of_platform_bus_create+0x294/0x35c > [ 0.032669] of_platform_populate+0x5c/0x150 > [ 0.032672] of_platform_default_populate_init+0xd0/0xec > [ 0.032697] do_one_initcall+0x4c/0x2e0 > [ 0.032701] do_initcalls+0x100/0x13c > [ 0.032707] kernel_init_freeable+0x1c8/0x21c > [ 0.032712] kernel_init+0x28/0x140 > [ 0.032731] ret_from_fork+0x10/0x20 > [ 0.032735] ---[ end trace 0000000000000000 ]--- > > In Linux, a check is applied to every device which is exposed through > device-tree node. The warning message is raised when the device isn't > DMA coherent and the cache line size is larger than ARCH_DMA_MINALIGN > (128 bytes). The cache line is sorted from CTR_EL0[CWG], which corresponds > to 256 bytes on the guest CPUs. The DMA coherent capability is claimed > through 'dma-coherent' in their device-tree nodes or parent nodes. > > Fix the issue by adding 'dma-coherent' property to the device-tree root > node, meaning all devices are capable of DMA coherent by default. > > Signed-off-by: Zhenyu Zhang Aligns with earlier discussion so... Reviewed-by: Jonathan Cameron > --- > v3: Add comments explaining why we add 'dma-coherent' property (Peter) > --- > hw/arm/virt.c | 11 +++++++++++ > 1 file changed, 11 insertions(+) > > diff --git a/hw/arm/virt.c b/hw/arm/virt.c > index 3c93c0c0a6..3cefac6d43 100644 > --- a/hw/arm/virt.c > +++ b/hw/arm/virt.c > @@ -271,6 +271,17 @@ static void create_fdt(VirtMachineState *vms) > qemu_fdt_setprop_cell(fdt, "/", "#size-cells", 0x2); > qemu_fdt_setprop_string(fdt, "/", "model", "linux,dummy-virt"); > > + /* > + * For QEMU, all DMA is coherent. Advertising this in the root node > + * has two benefits: > + * > + * - It avoids potential bugs where we forget to mark a DMA > + * capable device as being dma-coherent > + * - It avoids spurious warnings from the Linux kernel about > + * devices which can't do DMA at all > + */ > + qemu_fdt_setprop(fdt, "/", "dma-coherent", NULL, 0); > + > /* /chosen must exist for load_dtb to fill in necessary properties later */ > qemu_fdt_add_subnode(fdt, "/chosen"); > if (vms->dtb_randomness) {