Grub takes a long time to start when EFI is slow to respond

Hello list,

I have already written this post on the Dev ML a few weeks ago but it got little attention. Maybe someone here would be interested in giving their opinion on this issue since I am trying to figure out if this should be labeled as a bug or not.

There is an issue currently impacting the start times of grub. When grub 
is starting in a UEFI environment there are certain scenarios where it 
could take multiple minutes for grub to show the grub menu. The reason 
is that during initialization when invoking the function 
"grub_efidisk_read" in disk/efi/efidisk.c, the EFI read calls take a 
long time to return (sometimes multiple minutes) when trying to read 
sectors from certain disks. In the scenario I've seen I was manually 
triggering a Downstream Port Containment (DPC) from the UEFI shell which 
was disabling one of the drives (The operating system is NOT on this 
drive) and so when grub iterates through the disks during its startup, 
it it would hang waiting for the EFI firmware to respond and eventually 
receives an error from the firmware telling it that the read operation 
failed. Grub eventually is able to get to the grub menu but with a big 
delay (around 10 minutes) and is able to boot the operating system just 
fine.

 From my testing grub is trying to read multiple sectors from the same 
disk with each read operation taking over 2 minutes to complete.

This scenario should be reproducible in any case that would lead the 
firmware to hang on a read operation. In theory it can be a disk that is 
dying, buggy firmware, an NVME drive hit by DPC like in this case, etc.

The question on my mind is if this is something that grub should somehow 
handle (i.e having firmware calls taking a long time to return) or leave 
it as is and put the responsibility on the firmware to be more timely 
and respond sooner with an error code?

Thanks.