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 15FFD211BA465 for ; Mon, 28 Jan 2019 07:01:29 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7992A369BC; Mon, 28 Jan 2019 15:01:28 +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 C88115C553; Mon, 28 Jan 2019 15:01:26 +0000 (UTC) To: Tan Xiaojun Cc: Mark Rutland , Ard Biesheuvel , Marc Zyngier , "edk2-devel@lists.01.org" , Christoffer Dall 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> <70ec9046-cb9d-74e8-e64c-4d5fbeba4bfb@redhat.com> <5C4EFF06.2050600@huawei.com> From: Laszlo Ersek Message-ID: Date: Mon, 28 Jan 2019 16:01:10 +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: <5C4EFF06.2050600@huawei.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Mon, 28 Jan 2019 15:01:28 +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 15:01:30 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 01/28/19 14:09, Tan Xiaojun wrote: > On 2019/1/28 19:54, Laszlo Ersek wrote: >> 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. >> > > I don't understand, what do you want me to do? What is the specific problem? Sorry, I was unclear. Primarily, please see Mark's explanation. Secondarily, my point was that the upstream community could help more if the symptom reproduced on a pristine upstream host kernel. Given that I don't have access to your hardware that presents the symptom, plus that the symptom doesn't reproduce on hardware that I do have access to, using the downstream kernel that you reported, only you can attempt to repro the issue with an upstream kernel (and then please report the findings here). Thanks, Laszlo