Arnd --
Your commit a07b50d80ab62 ("hyperv: avoid dependency on screen_info") [1]
introduced a subtle bug. The commit message says, in part:
Similarly, the vmbus_drv code marks the original EFI framebuffer as
reserved, but this is not required if there is no sysfb.
This statement turns out to be false. In a Generation 2 VM, if it is not
reserved, a PCI-passthru NVMe device that contains the OS partition can
try to use the framebuffer's MMIO space. Doing so causes Hyper-V to
report an error to Linux when Linux is probing the NVMe device. The
OS disk fails to get setup, and Linux then fails to boot in the VM.
Hyper-V VM configurations with a PCI-passthru NVMe device as the
OS disk are relatively rare at the moment, and the Linux images
for the Azure cloud usually have CONFIG_FB_EFI=y, so that
CONFIG_SYSFB is "y". So the problem hasn't typically shown up.
But PCI pass-thru NVMe OS disks will become increasingly common,
with the potential for boot failure if CONFIG_SYSFB is "n". I
recently stumbled across this problem, and it took a while to
figure out why my kernel wouldn't boot.
The Hyper-V host provides the guest with ACPI tables describing
the overall MMIO space available to the guest. But the location of
the Hyper-V synthetic framebuffer is only communicated to the guest
via screen_info. It's not in the ACPI tables. Maybe that's the real
underlying problem, but it is what it is.
I don't have a full perspective on your goals and status in making
screen_info more local to the sysfb helper code. So I'm soliciting
your input on how to solve this problem. I have two ideas to run
by you:
1) In Kconfig, have CONFIG_HYPERV select SYSFB. This way
Hyper-V guests will always have CONFIG_SYSFB=y, even if none
of FB_VESA, FB_EFI, or SYSFB_SIMPLEFB is selected. The VMBus
driver will always properly reserve the MMIO space for the
synthetic framebuffer.
2) If #1 is objectionable, the next best thing is for the VMBus
driver to "guess" where the synthetic framebuffer is, and reserve
that MMIO space. The "guess" would be that the synthetic
framebuffer is always at the beginning of the MMIO space reported
in the ACPI tables, with a size of 8 MiB. That's what Hyper-V seems
to always do today, though it's not a guaranteed contract. But
that would prevent an NVMe device from trying to use that
MMIO space and failing. It's a hack but probably better than
leaving things as they currently are.
The problem can currently happen only on x86/x64 VMs,
but will probably be possible on arm64 VMs as well at some
point in the future.
Any input is appreciated. Thanks.
Michael
[1]
https://lore.kernel.org/linux-hyperv/20231009211845.3136536-9-a...@kernel.org/
