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 <ler...@redhat.com> 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 _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
