Re: [PATCH] ArmPkg: update InvalidateInstructionCacheRange to flush only to PoU

[Laszlo Ersek <lersek@redhat.com>]

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 <lersek@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.
>>
> 
> 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