From mboxrd@z Thu Jan 1 00:00:00 1970 Received: by 2002:a17:906:28cf:b0:a52:4db9:938b with SMTP id p15csp1570043ejd; Thu, 18 Apr 2024 01:16:27 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCXEN/S8lEBXzmfzQYC86WC3SGjIgRKVfoUPohBlDSJb8kke+Gk/sVR/KK7fSfjeia9S3S4mCGY2rsCHeUI5vLbIC87+NxBv X-Google-Smtp-Source: AGHT+IHXp3Cg8vI9E/v3bzcCp5uamHtskY0jg6eYqTyCQRhDETs6/jmsRUFQO3+Dp5amE3zr++y5 X-Received: by 2002:ad4:500b:0:b0:6a0:582d:b4bf with SMTP id s11-20020ad4500b000000b006a0582db4bfmr529949qvo.27.1713428187124; Thu, 18 Apr 2024 01:16:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1713428187; cv=none; d=google.com; s=arc-20160816; b=cNuQYWCGo9dRPhk3PM3bCE+Suc7oyISU+21agVqRDeHpZyTLyQd2e7SBPgpGkh3TzK 1G2kf2zwgk26TjI78QXarln1ieba749Cc/4TaJqXPHBPgxRckNPSHNnSc3dx6srOb8Wv yMEZcUiEyNgUfOagepBBhuWHHNpvDLpNf8GGPyahcOXh0wfTQYJtd0Pkk3n8lXR3A2H/ aV1eaiofClvXjpOjV3jJthMpnad9sm+L5ylILJ0JHcfXsanVgd/zMKYxgsRRJR65i5dL 3Vi6+R/uceqFOlvZ5UVjT4zL8bN3JwbHnlBRCAAh2RwU3jCqFt44/41EBOFx/W49SalD Fy1A== 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=62mA9kWBl6rNhwgcKetLh06gyGC3fEnKCyIht4Ys5vE=; fh=KjSYjhGl8givcv6vWyPkD+c3THMMoXDtefKQslEFMA0=; b=TxwXB5FSTVygSPxgaUv9KZ4omzrVdsfi7EFj6NDp7NtdtjTsIjNFfP9ge8R5sfDjx2 Ta0ga22yT65FFw7zjQl3SOLJfHPdqPqrDzr71Z0cjTAy+uQZ5XXLJyOUJOEupmKAhM07 VeJYLckSHlrIZjR8tn4zXmsXxyvQX2uiF0XdgcNohQt3/o4E4nhlBmUcEDnMXyN/IAX5 f5R0MGCndVAaTSbppjkD8+LAKwcAEe9Y1nSCrEreMp9oQ/zzNxlC5SylW7xOQzsS7YGO H+JRxcHRppRBfk3cvzDrQk29qDRxWW1akjIDhc+9o/NjF/zht4Nk3tbp39imjeZMDE1a rDPw==; 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 if4-20020a0562141c4400b006a0423b368dsi954203qvb.325.2024.04.18.01.16.26 for (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Thu, 18 Apr 2024 01:16:27 -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 1rxMwJ-0001ui-LO; Thu, 18 Apr 2024 04:16:16 -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 1rxMwI-0001uL-1h; Thu, 18 Apr 2024 04:16:14 -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 1rxMwE-0006Tn-Ms; Thu, 18 Apr 2024 04:16:13 -0400 Received: from mail.maildlp.com (unknown [172.18.186.216]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4VKrC36F1mz6K5qR; Thu, 18 Apr 2024 16:13:51 +0800 (CST) Received: from lhrpeml500005.china.huawei.com (unknown [7.191.163.240]) by mail.maildlp.com (Postfix) with ESMTPS id D8A22140684; Thu, 18 Apr 2024 16:15:54 +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.35; Thu, 18 Apr 2024 09:15:54 +0100 Date: Thu, 18 Apr 2024 09:15:55 +0100 To: Richard Henderson CC: , , Philippe =?ISO-8859-1?Q?Ma?= =?ISO-8859-1?Q?thieu-Daud=E9?= , Idan Horowitz , Subject: Re: [PATCH v3 5/6] target/arm: Do memory type alignment check when translation disabled Message-ID: <20240418091555.00006666@Huawei.com> In-Reply-To: <0c878d25-3fbb-4f0b-bc9e-ca638f8c4f1e@linaro.org> References: <20240301204110.656742-1-richard.henderson@linaro.org> <20240301204110.656742-6-richard.henderson@linaro.org> <20240416161111.0000607c@huawei.com> <0c878d25-3fbb-4f0b-bc9e-ca638f8c4f1e@linaro.org> 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="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Originating-IP: [10.202.227.76] X-ClientProxiedBy: lhrpeml100001.china.huawei.com (7.191.160.183) 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_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 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: CWfPqoUjZDDR On Wed, 17 Apr 2024 13:07:35 -0700 Richard Henderson wrote: > On 4/16/24 08:11, Jonathan Cameron wrote: > > On Fri, 1 Mar 2024 10:41:09 -1000 > > Richard Henderson wrote: > > =20 > >> If translation is disabled, the default memory type is Device, which > >> requires alignment checking. This is more optimally done early via > >> the MemOp given to the TCG memory operation. > >> > >> Reviewed-by: Philippe Mathieu-Daud=E9 > >> Reported-by: Idan Horowitz > >> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1204 > >> Signed-off-by: Richard Henderson =20 > >=20 > > Hi Richard. > >=20 > > I noticed some tests I was running stopped booting with master. > > (it's a fun and complex stack of QEMU + kvm on QEMU for vCPU Hotplug ke= rnel work, > > but this is the host booting) > >=20 > > EDK2 build from upstream as of somepoint last week. > >=20 > > Bisects to this patch. > >=20 > > qemu-system-aarch64 -M virt,gic-version=3D3,virtualization=3Dtrue -m = 4g,maxmem=3D8G,slots=3D8 -cpu cortex-a76 -smp cpus=3D4,threads=3D2,clusters= =3D2,sockets=3D1 \ > > -kernel Image \ > > -drive if=3Dnone,file=3Dfull.qcow2,format=3Dqcow2,id=3Dhd \ > > -device ioh3420,id=3Droot_port1 -device virtio-blk-pci,drive=3Dhd \ > > -netdev user,id=3Dmynet,hostfwd=3Dtcp::5555-:22 -device virtio-net-pc= i,netdev=3Dmynet,id=3Dbob \ > > -nographic -no-reboot -append 'earlycon root=3D/dev/vda2 fsck.mode=3D= skip tp_printk' \ > > -monitor telnet:127.0.0.1:1235,server,nowait -bios QEMU_EFI.fd \ > > -object memory-backend-ram,size=3D4G,id=3Dmem0 \ > > -numa node,nodeid=3D0,cpus=3D0-3,memdev=3Dmem0 > >=20 > > Symptoms: Nothing on console from edk2 which is built in debug mode so = is normally very noisy. > > No sign of anything much happening at all :( =20 >=20 > This isn't a fantastic bug report. >=20 > (1) If it doesn't boot efi, then none of the -kernel parameters are neces= sary. > (2) I'd be surprised if the full.qcow2 drive parameters are necessary eit= her. > But if they are, what contents? Is a new empty drive sufficient, ju= st > enough to send the bios through the correct device initialization? > (3) edk2 build from ... > Well, this is partly edk2's fault, as the build documentation is awf= ul. > I spent an entire afternoon trying to figure it out and gave up. >=20 > I will say that the edk2 shipped with qemu does work, so... are you absol= utely > certain that it isn't a bug in edk2 since then? Firmware bugs are exactl= y what > that patch is supposed to expose, as requested by issue #1204. >=20 > I'd say you should boot with "-d int" and see what kind of interrupts you= 're getting very=20 > early on. I suspect that you'll see data aborts with ESR xx/yy where the= last 6 bits of=20 > yy are 0x21 (alignment fault). Hi Richard, Sorry for lack of details, I was aware it wasn't great and should have stat= ed I planned to come back with more details when I had time to debug. Snowed under so f= or now I've just dropped back to 8.2 and will get back to this perhaps next week. Jonathan >=20 >=20 > r~ 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 8281BC04FF8 for ; Thu, 18 Apr 2024 08:17:12 +0000 (UTC) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rxMwK-0001uj-AB; Thu, 18 Apr 2024 04:16:16 -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 1rxMwI-0001uL-1h; Thu, 18 Apr 2024 04:16:14 -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 1rxMwE-0006Tn-Ms; Thu, 18 Apr 2024 04:16:13 -0400 Received: from mail.maildlp.com (unknown [172.18.186.216]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4VKrC36F1mz6K5qR; Thu, 18 Apr 2024 16:13:51 +0800 (CST) Received: from lhrpeml500005.china.huawei.com (unknown [7.191.163.240]) by mail.maildlp.com (Postfix) with ESMTPS id D8A22140684; Thu, 18 Apr 2024 16:15:54 +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.35; Thu, 18 Apr 2024 09:15:54 +0100 Date: Thu, 18 Apr 2024 09:15:55 +0100 To: Richard Henderson CC: , , Philippe =?ISO-8859-1?Q?Ma?= =?ISO-8859-1?Q?thieu-Daud=E9?= , Idan Horowitz , Subject: Re: [PATCH v3 5/6] target/arm: Do memory type alignment check when translation disabled Message-ID: <20240418091555.00006666@Huawei.com> In-Reply-To: <0c878d25-3fbb-4f0b-bc9e-ca638f8c4f1e@linaro.org> References: <20240301204110.656742-1-richard.henderson@linaro.org> <20240301204110.656742-6-richard.henderson@linaro.org> <20240416161111.0000607c@huawei.com> <0c878d25-3fbb-4f0b-bc9e-ca638f8c4f1e@linaro.org> 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="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Originating-IP: [10.202.227.76] X-ClientProxiedBy: lhrpeml100001.china.huawei.com (7.191.160.183) 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_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 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 Wed, 17 Apr 2024 13:07:35 -0700 Richard Henderson wrote: > On 4/16/24 08:11, Jonathan Cameron wrote: > > On Fri, 1 Mar 2024 10:41:09 -1000 > > Richard Henderson wrote: > > =20 > >> If translation is disabled, the default memory type is Device, which > >> requires alignment checking. This is more optimally done early via > >> the MemOp given to the TCG memory operation. > >> > >> Reviewed-by: Philippe Mathieu-Daud=E9 > >> Reported-by: Idan Horowitz > >> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1204 > >> Signed-off-by: Richard Henderson =20 > >=20 > > Hi Richard. > >=20 > > I noticed some tests I was running stopped booting with master. > > (it's a fun and complex stack of QEMU + kvm on QEMU for vCPU Hotplug ke= rnel work, > > but this is the host booting) > >=20 > > EDK2 build from upstream as of somepoint last week. > >=20 > > Bisects to this patch. > >=20 > > qemu-system-aarch64 -M virt,gic-version=3D3,virtualization=3Dtrue -m = 4g,maxmem=3D8G,slots=3D8 -cpu cortex-a76 -smp cpus=3D4,threads=3D2,clusters= =3D2,sockets=3D1 \ > > -kernel Image \ > > -drive if=3Dnone,file=3Dfull.qcow2,format=3Dqcow2,id=3Dhd \ > > -device ioh3420,id=3Droot_port1 -device virtio-blk-pci,drive=3Dhd \ > > -netdev user,id=3Dmynet,hostfwd=3Dtcp::5555-:22 -device virtio-net-pc= i,netdev=3Dmynet,id=3Dbob \ > > -nographic -no-reboot -append 'earlycon root=3D/dev/vda2 fsck.mode=3D= skip tp_printk' \ > > -monitor telnet:127.0.0.1:1235,server,nowait -bios QEMU_EFI.fd \ > > -object memory-backend-ram,size=3D4G,id=3Dmem0 \ > > -numa node,nodeid=3D0,cpus=3D0-3,memdev=3Dmem0 > >=20 > > Symptoms: Nothing on console from edk2 which is built in debug mode so = is normally very noisy. > > No sign of anything much happening at all :( =20 >=20 > This isn't a fantastic bug report. >=20 > (1) If it doesn't boot efi, then none of the -kernel parameters are neces= sary. > (2) I'd be surprised if the full.qcow2 drive parameters are necessary eit= her. > But if they are, what contents? Is a new empty drive sufficient, ju= st > enough to send the bios through the correct device initialization? > (3) edk2 build from ... > Well, this is partly edk2's fault, as the build documentation is awf= ul. > I spent an entire afternoon trying to figure it out and gave up. >=20 > I will say that the edk2 shipped with qemu does work, so... are you absol= utely > certain that it isn't a bug in edk2 since then? Firmware bugs are exactl= y what > that patch is supposed to expose, as requested by issue #1204. >=20 > I'd say you should boot with "-d int" and see what kind of interrupts you= 're getting very=20 > early on. I suspect that you'll see data aborts with ESR xx/yy where the= last 6 bits of=20 > yy are 0x21 (alignment fault). Hi Richard, Sorry for lack of details, I was aware it wasn't great and should have stat= ed I planned to come back with more details when I had time to debug. Snowed under so f= or now I've just dropped back to 8.2 and will get back to this perhaps next week. Jonathan >=20 >=20 > r~