From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=209.132.183.28; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@ml01.01.org Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 2EC1C211AEA71 for ; Mon, 28 Jan 2019 03:54:56 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 1243187648; Mon, 28 Jan 2019 11:54:56 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-224.rdu2.redhat.com [10.10.120.224]) by smtp.corp.redhat.com (Postfix) with ESMTP id 726E827BDF; Mon, 28 Jan 2019 11:54:54 +0000 (UTC) To: Mark Rutland Cc: Ard Biesheuvel , Marc Zyngier , "edk2-devel@lists.01.org" , Christoffer Dall , Tanxiaojun References: <1449471969-16949-1-git-send-email-ard.biesheuvel@linaro.org> <2dd4294c-76f0-f433-cbd2-bf0b37114aee@redhat.com> <12fa0861-e25d-eba7-48ea-2bd7d47d58fb@redhat.com> <20190128104634.xnaivxxbvad7jffo@blommer> From: Laszlo Ersek Message-ID: <70ec9046-cb9d-74e8-e64c-4d5fbeba4bfb@redhat.com> Date: Mon, 28 Jan 2019 12:54:53 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20190128104634.xnaivxxbvad7jffo@blommer> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Mon, 28 Jan 2019 11:54:56 +0000 (UTC) Subject: Re: [PATCH] ArmPkg: update InvalidateInstructionCacheRange to flush only to PoU X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2019 11:54:57 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 01/28/19 11:46, Mark Rutland wrote: > On Wed, Jan 23, 2019 at 10:54:56AM +0100, Laszlo Ersek wrote: >> On 01/23/19 10:26, Ard Biesheuvel wrote: >>> On Wed, 23 Jan 2019 at 10:14, Laszlo Ersek wrote: >>>> On 01/22/19 16:37, Ard Biesheuvel wrote: >> >>>>> Is SetUefiImageMemoryAttributes() being >>>>> called to remap the memory R-X ? >>>> >>>> No, it is not; the grub binary in question doesn't have the required >>>> section alignment (... I hope at least that that's what your question >>>> refers to): >>>> >>>>> ProtectUefiImageCommon - 0x3E6C54C0 >>>>> - 0x000000013BEEF000 - 0x0000000000030600 >>>>> !!!!!!!! ProtectUefiImageCommon - Section Alignment(0x200) is >>>> incorrect !!!!!!!! >>> >>> This is puzzling, given that the exact same binary works on Mustang. >> >> And even on the original (unspecified) hardware, the same binary works >> frequently. My understanding is that there are five VMs executing reboot >> loops in parallel, on the same host, and 4 out of 5 may hit the issue in >> a reasonable time period (300 reboots or so). > > Interesting. > > Do you happen to know how many VMID bits the host has? If it has an 8-bit VMID, > this could be indicative of some problem upon overflow. I'll let Tan Xiaojun (CC'd) answer this questions. > Can you point us at the host kernel? In the report, Tan Xiaojun wrote "4.18.0-48.el8.aarch64"; I guess that information is mostly useless in an upstream discussion. Unfortunately, I couldn't reproduce the symptom at all (I know nothing about the hardware in question), so I can't myself retest with an upstream host kernel. Thank you! Laszlo