From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=217.140.101.70; helo=foss.arm.com; envelope-from=mark.rutland@arm.com; receiver=edk2-devel@ml01.01.org Received: from foss.arm.com (usa-sjc-mx-foss1.foss.arm.com [217.140.101.70]) by ml01.01.org (Postfix) with ESMTP id 40C3C211A6D56 for ; Mon, 28 Jan 2019 02:46:40 -0800 (PST) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id BB2D3EBD; Mon, 28 Jan 2019 02:46:39 -0800 (PST) Received: from blommer (usa-sjc-mx-foss1.foss.arm.com [217.140.101.70]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 124003F589; Mon, 28 Jan 2019 02:46:37 -0800 (PST) Date: Mon, 28 Jan 2019 10:46:34 +0000 From: Mark Rutland To: Laszlo Ersek Cc: Ard Biesheuvel , Marc Zyngier , "edk2-devel@lists.01.org" , Christoffer Dall , Tanxiaojun Message-ID: <20190128104634.xnaivxxbvad7jffo@blommer> 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> MIME-Version: 1.0 In-Reply-To: <12fa0861-e25d-eba7-48ea-2bd7d47d58fb@redhat.com> User-Agent: NeoMutt/20170113 (1.7.2) 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 10:46:40 -0000 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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. Can you point us at the host kernel? Thanks, Mark.