Bugzilla – Bug 1219180
Missing framebuffer during boot on aarch64
Last modified: 2024-05-17 08:52:20 UTC
Unless the initrd is built with the platform native DRM driver (e.g. virtio_gpu), there is no graphical output during boot. This also means that entering a passphrase for unlocking the root fs is not possible. On x86 it uses the EFI framebuffer successfully, but on aarch64 dmesg has no trace of efifb/simplefb/simpledrm. ## Observation openQA test in scenario microos-Tumbleweed-MicroOS-Image-sdboot-aarch64-microos-wizard@aarch64 fails in [ansible](https://openqa.opensuse.org/tests/3891664/modules/ansible/steps/31) ## Test suite description Like MicroOS, but use neither combustion nor ignition for the intial configuration, so jeos-firstboot runs. ## Reproducible Fails since (at least) Build [20231129](https://openqa.opensuse.org/tests/3771195) ## Expected result Last good: [20231127](https://openqa.opensuse.org/tests/3763820) (or more recent) ## Further details Always latest result in this scenario: [latest](https://openqa.opensuse.org/tests/latest?arch=aarch64&distri=microos&flavor=MicroOS-Image-sdboot&machine=aarch64&test=microos-wizard&version=Tumbleweed)
Ping
This uses virtio_gpu. I assume it runs in an emulator or virtual machine?
(In reply to Thomas Zimmermann from comment #2) > This uses virtio_gpu. I assume it runs in an emulator or virtual machine? Correct. Other emulated hardware didn't work either (IIRC -vga std)
(In reply to Fabian Vogt from comment #3) > (In reply to Thomas Zimmermann from comment #2) > > This uses virtio_gpu. I assume it runs in an emulator or virtual machine? > > Correct. Other emulated hardware didn't work either (IIRC -vga std) VGA requires a VGA BIOS, which is x86 code. Under regular aarch64 systems (e.g., Rpi) the firmware's framebuffer is listed in the device tree. But there is no DT here; just UEFI. I've installed MicroOS in Aarch64 qemu to test. The kernel config is correct. There is some support for graphics in the early boot stages (GRUB).
(In reply to Thomas Zimmermann from comment #4) > (In reply to Fabian Vogt from comment #3) > > (In reply to Thomas Zimmermann from comment #2) > > > This uses virtio_gpu. I assume it runs in an emulator or virtual machine? > > > > Correct. Other emulated hardware didn't work either (IIRC -vga std) > > VGA requires a VGA BIOS, which is x86 code. If the firmware interface and GRUB have video output, GOP is present, so this shouldn't matter. > Under regular aarch64 systems (e.g., Rpi) the firmware's framebuffer is > listed in the device tree. But there is no DT here; just UEFI. > > I've installed MicroOS in Aarch64 qemu to test. The kernel config is > correct. There is some support for graphics in the early boot stages (GRUB). Does efifb need more than just EFI GOP availability?
Here are the results of my investigation so far. The kernel tries to acquire the UEFI boot framebuffer via find_gop() [1]. It fails for all available results at the pixel_format test at [2]. The firmware only supports the BitBlt() EFI call to read/write framebuffer data. It's a boot service, so it's gone after the kernel initialized. We cannot use it. I've tested with kernel's going back to v6.4. It's always reproducible. To fix this problem, we have modify qemu's OVMF firmware to provide a pixel format and a framebuffer to which we can memcpy(). AFAICT a pixel format of PIXEL_BIT_MASK [3] would do this. [1] https://elixir.bootlin.com/linux/v6.8/source/drivers/firmware/efi/libstub/gop.c#L521 [2] https://elixir.bootlin.com/linux/v6.8/source/drivers/firmware/efi/libstub/gop.c#L489 [3] https://elixir.bootlin.com/linux/v6.8/source/drivers/firmware/efi/libstub/efistub.h#L519
That explains it. Looking at the EDK II source, the driver for virtio-gpu-pci does not expose a linear framebuffer, only virtio-vga does (https://github.com/tianocore/edk2/blob/952b5cf94c8727b65e04d3d507c0134743be2a66/OvmfPkg/Virtio10Dxe/Virtio10.c#L1029). virtio-vga is not available in qemu-system-aarch64 though. So a question for the virtualization team (qemu + ovmf): What's the right controller to use to get this to work? I guess ramfb might work but it's too limited to be usable in practice.
(In reply to Fabian Vogt from comment #0) > ## Reproducible > > Fails since (at least) Build > [20231129](https://openqa.opensuse.org/tests/3771195) > > > ## Expected result > > Last good: [20231127](https://openqa.opensuse.org/tests/3763820) (or more > recent) > So, I'm curious about this part. Does these "Fails since" and "Last good" mean that this was working at some point, and then it broke? I'm asking because, AFAIK, graphical output until virtio-gpu.ko is loaded has always been the case (but I may be wrong, as I'm not much of an expert of ARM)...
(In reply to Fabian Vogt from comment #7) > That explains it. Looking at the EDK II source, the driver for > virtio-gpu-pci does not expose a linear framebuffer, only virtio-vga does > (https://github.com/tianocore/edk2/blob/ > 952b5cf94c8727b65e04d3d507c0134743be2a66/OvmfPkg/Virtio10Dxe/Virtio10. > c#L1029). virtio-vga is not available in qemu-system-aarch64 though. > Sorry, but I also am not sure I understand this part. What do you mean with "virtio-vga is not available in qemu-system-aarch64" ?
(In reply to Dario Faggioli from comment #9) > (In reply to Fabian Vogt from comment #7) > > That explains it. Looking at the EDK II source, the driver for > > virtio-gpu-pci does not expose a linear framebuffer, only virtio-vga does > > (https://github.com/tianocore/edk2/blob/ > > 952b5cf94c8727b65e04d3d507c0134743be2a66/OvmfPkg/Virtio10Dxe/Virtio10. > > c#L1029). virtio-vga is not available in qemu-system-aarch64 though. > > > Sorry, but I also am not sure I understand this part. > > What do you mean with "virtio-vga is not available in qemu-system-aarch64" ? As per: https://qemu-project.gitlab.io/qemu/system/arm/virt.html For ARM, "The recommended option is virtio-gpu-pci; this is the only one which will work correctly with KVM."
Hi Thomas, (In reply to Thomas Zimmermann from comment #6) > Here are the results of my investigation so far. The kernel tries to acquire > the UEFI boot framebuffer via find_gop() [1]. It fails for all available > results at the pixel_format test at [2]. The firmware only supports the > BitBlt() EFI call to read/write framebuffer data. It's a boot service, so > it's gone after the kernel initialized. We cannot use it. > > I've tested with kernel's going back to v6.4. It's always reproducible. > > To fix this problem, we have modify qemu's OVMF firmware to provide a pixel > format and a framebuffer to which we can memcpy(). AFAICT a pixel format of > PIXEL_BIT_MASK [3] would do this. > > [1] > https://elixir.bootlin.com/linux/v6.8/source/drivers/firmware/efi/libstub/ > gop.c#L521 > [2] > https://elixir.bootlin.com/linux/v6.8/source/drivers/firmware/efi/libstub/ > gop.c#L489 > [3] > https://elixir.bootlin.com/linux/v6.8/source/drivers/firmware/efi/libstub/ > efistub.h#L519 Could you please teach me how to create a qemu of aarch64 with graphics window? I used the following qemu command for launching a aarch64 guest. But it always only shows message on terminal console. Not graphic window: qemu-system-aarch64 \ -m 4096 -cpu cortex-a57 -smp 4 -M virt \ -drive if=pflash,format=raw,readonly,file=/usr/share/qemu/aavmf-aarch64-code.bin \ -drive if=pflash,format=raw,file=/home/joeyli/qemu-vm/openSUSE-MicroOS-aarch64-vars-store.bin \ -serial mon:stdio \ -net nic,model=virtio -net nic,model=virtio -net bridge,br=br0,helper=/usr/libexec/qemu-bridge-helper \ -drive if=none,file=/home/joeyli/iso/openSUSE-MicroOS-DVD-aarch64-Current.iso,id=hd0 -device virtio-blk-device,drive=hd0 \ -drive if=none,file=/home/joeyli/qemu-vm/openSUSE-MicroOS-aarch64-efi.qcow2,id=hd1 -device virtio-blk-device,drive=hd1 -vnc :93 Thanks!
(In reply to Joey Lee from comment #12) > Hi Thomas, > [...snip] > > Could you please teach me how to create a qemu of aarch64 with graphics > window? I used the following qemu command for launching a aarch64 guest. But > it always only shows message on terminal console. Not graphic window: > > qemu-system-aarch64 \ > -m 4096 -cpu cortex-a57 -smp 4 -M virt \ > -drive > if=pflash,format=raw,readonly,file=/usr/share/qemu/aavmf-aarch64-code.bin \ > -drive > if=pflash,format=raw,file=/home/joeyli/qemu-vm/openSUSE-MicroOS-aarch64-vars- > store.bin \ > -serial mon:stdio \ > -net nic,model=virtio -net nic,model=virtio -net > bridge,br=br0,helper=/usr/libexec/qemu-bridge-helper \ > -drive > if=none,file=/home/joeyli/iso/openSUSE-MicroOS-DVD-aarch64-Current.iso, > id=hd0 -device virtio-blk-device,drive=hd0 \ > -drive > if=none,file=/home/joeyli/qemu-vm/openSUSE-MicroOS-aarch64-efi.qcow2,id=hd1 > -device virtio-blk-device,drive=hd1 -vnc :93 > > Thanks! I have removed "-vnc :93" then using sudo to run the above command. But then I got "gtk initialization failed".
For me it worked to use qemu-kvm -M virt -m 4096M -bios /usr/share/qemu/aavmf-aarch64-code.bin -cpu host -device virtio-gpu-pci ... -device qemu-xhci -device usb-kbd ...
(In reply to Joey Lee from comment #13) > (In reply to Joey Lee from comment #12) > > Hi Thomas, > > > [...snip] > > > > Could you please teach me how to create a qemu of aarch64 with graphics > > window? I used the following qemu command for launching a aarch64 guest. But > > it always only shows message on terminal console. Not graphic window: > > > > qemu-system-aarch64 \ > > -m 4096 -cpu cortex-a57 -smp 4 -M virt \ > > -drive > > if=pflash,format=raw,readonly,file=/usr/share/qemu/aavmf-aarch64-code.bin \ > > -drive > > if=pflash,format=raw,file=/home/joeyli/qemu-vm/openSUSE-MicroOS-aarch64-vars- > > store.bin \ > > -serial mon:stdio \ > > -net nic,model=virtio -net nic,model=virtio -net > > bridge,br=br0,helper=/usr/libexec/qemu-bridge-helper \ > > -drive > > if=none,file=/home/joeyli/iso/openSUSE-MicroOS-DVD-aarch64-Current.iso, > > id=hd0 -device virtio-blk-device,drive=hd0 \ > > -drive > > if=none,file=/home/joeyli/qemu-vm/openSUSE-MicroOS-aarch64-efi.qcow2,id=hd1 > > -device virtio-blk-device,drive=hd1 -vnc :93 > > > > Thanks! > > I have removed "-vnc :93" then using sudo to run the above command. But then > I got "gtk initialization failed". After removed "-serial mon:stdio", the qemu window is opened. But the installation of MicroOS iso is NOT started. With "-serial mon:stdio", the installation process is started. How could I open an qemu window with root account?
(In reply to Joey Lee from comment #12) > Hi Thomas, > > (In reply to Thomas Zimmermann from comment #6) > > Here are the results of my investigation so far. The kernel tries to acquire > > the UEFI boot framebuffer via find_gop() [1]. It fails for all available > > results at the pixel_format test at [2]. The firmware only supports the > > BitBlt() EFI call to read/write framebuffer data. It's a boot service, so > > it's gone after the kernel initialized. We cannot use it. > > > > I've tested with kernel's going back to v6.4. It's always reproducible. > > > > To fix this problem, we have modify qemu's OVMF firmware to provide a pixel > > format and a framebuffer to which we can memcpy(). AFAICT a pixel format of > > PIXEL_BIT_MASK [3] would do this. > > > > [1] > > https://elixir.bootlin.com/linux/v6.8/source/drivers/firmware/efi/libstub/ > > gop.c#L521 > > [2] > > https://elixir.bootlin.com/linux/v6.8/source/drivers/firmware/efi/libstub/ > > gop.c#L489 > > [3] > > https://elixir.bootlin.com/linux/v6.8/source/drivers/firmware/efi/libstub/ > > efistub.h#L519 > > Could you please teach me how to create a qemu of aarch64 with graphics > window? I used the following qemu command for launching a aarch64 guest. But > it always only shows message on terminal console. Not graphic window: > > qemu-system-aarch64 \ > -m 4096 -cpu cortex-a57 -smp 4 -M virt \ Hi @joey, any reason why you are running with cortex-a57 and TCG? The supported environment for AArch64 is KVM, with cpu host. Here is again the set of recommendations for ARM KVM from the QEMU manual: https://www.qemu.org/docs/master/system/target-arm.html https://www.qemu.org/docs/master/system/arm/virt.html This would avoid a lot of trial and error and unsupported combinations: lets test what is actually supported upstream and downstream. Thanks, C > -drive > if=pflash,format=raw,readonly,file=/usr/share/qemu/aavmf-aarch64-code.bin \ > -drive > if=pflash,format=raw,file=/home/joeyli/qemu-vm/openSUSE-MicroOS-aarch64-vars- > store.bin \ > -serial mon:stdio \ > -net nic,model=virtio -net nic,model=virtio -net > bridge,br=br0,helper=/usr/libexec/qemu-bridge-helper \ > -drive > if=none,file=/home/joeyli/iso/openSUSE-MicroOS-DVD-aarch64-Current.iso, > id=hd0 -device virtio-blk-device,drive=hd0 \ > -drive > if=none,file=/home/joeyli/qemu-vm/openSUSE-MicroOS-aarch64-efi.qcow2,id=hd1 > -device virtio-blk-device,drive=hd1 -vnc :93 > > Thanks!
Created attachment 874812 [details] libvirt aarch64 XML config I use libvirt and the rsp desktop helpers for handling virtual machines. IDK how that translates to qemu calls, but I've attached the machine's XML configuration.
(In reply to Dario Faggioli from comment #8) > (In reply to Fabian Vogt from comment #0) > > ## Reproducible > > > > Fails since (at least) Build > > [20231129](https://openqa.opensuse.org/tests/3771195) > > > > > > ## Expected result > > > > Last good: [20231127](https://openqa.opensuse.org/tests/3763820) (or more > > recent) > > > So, I'm curious about this part. Does these "Fails since" and "Last good" > mean that this was working at some point, and then it broke? In this particular case not, the change that started the failure just exposed this issue. I don't actually remember what it was. > I'm asking because, AFAIK, graphical output until virtio-gpu.ko is loaded > has always been the case (but I may be wrong, as I'm not much of an expert > of ARM)... I think so too.(In reply to Stefan Dirsch from comment #14) > For me it worked to use > > qemu-kvm -M virt -m 4096M -bios /usr/share/qemu/aavmf-aarch64-code.bin -cpu > host -device virtio-gpu-pci ... -device qemu-xhci -device usb-kbd ... On my x86_64 hosts I just do qemu-system-aarch64 -M virt -cpu cortex-a72 -m 2048 -serial stdio -device virtio-gpu-pci -device qemu-xhci -device usb-kbd -bios /usr/share/qemu/aavmf-aarch64-code.bin + whatever storage devices.
I am trying to install a aarch64 vm with qemu graphics window but it still failed. I can use the following command with root account to launch a openSUSE-MicroOS aarch64 installation process. The installation direct runs on serial console mode: qemu-system-aarch64 \ -m 4096 -cpu cortex-a57 -smp 4 -M virt \ -drive if=pflash,format=raw,readonly,file=/usr/share/qemu/aavmf-aarch64-code.bin \ -drive if=pflash,format=raw,file=/home/joeyli/qemu-vm/openSUSE-MicroOS-aarch64-vars-store.bin \ -serial mon:stdio \ -net nic,model=virtio -net nic,model=virtio -net bridge,br=br0,helper=/usr/libexec/qemu-bridge-helper \ -drive if=none,file=/home/joeyli/iso/openSUSE-MicroOS-DVD-aarch64-Current.iso,id=hd0 -device virtio-blk-device,drive=hd0 \ -drive if=none,file=/home/joeyli/qemu-vm/openSUSE-MicroOS-aarch64-efi.qcow2,id=hd1 -device virtio-blk-device,drive=hd1 -vnc :93 I have tried to remove "-vnc :93" and "-serial mon:stdio" qemu parameter and hope to launch the installation process in the qemu graphics window. The qemu graphics window is created, but I only got a QEMU window with (qemu) promopt. My command is: qemu-system-aarch64 \ -m 4096 -cpu cortex-a57 -smp 4 -M virt \ -drive if=pflash,format=raw,readonly,file=/usr/share/qemu/aavmf-aarch64-code.bin \ -drive if=pflash,format=raw,file=/home/joeyli/qemu-vm/openSUSE-MicroOS-aarch64-vars-store.bin \ -net nic,model=virtio -net nic,model=virtio -net bridge,br=br0,helper=/usr/libexec/qemu-bridge-helper \ -drive if=none,file=/home/joeyli/iso/openSUSE-MicroOS-DVD-aarch64-Current.iso,id=hd0 -device virtio-blk-device,drive=hd0 \ -drive if=none,file=/home/joeyli/qemu-vm/openSUSE-MicroOS-aarch64-efi.qcow2,id=hd1 -device virtio-blk-device,drive=hd1 I used root account the run the above command. The installation process does NOT show on qemu graphics window. I also tried non-root account, but I always got "usr/libexec/qemu-bridge-helper: bridge helper failed" message. Looks that the net bridge needs root permission. Then I back to root account. Using qemu-kvm and "-cpu host" as the following command: qemu-kvm \ -m 4096 -cpu host -smp 4 \ -drive if=pflash,format=raw,readonly,file=/usr/share/qemu/aavmf-aarch64-code.bin \ -drive if=pflash,format=raw,file=/home/joeyli/qemu-vm/openSUSE-MicroOS-aarch64-vars-store.bin \ -serial mon:stdio \ -net nic,model=virtio -net nic,model=virtio -net bridge,br=br0,helper=/usr/libexec/qemu-bridge-helper \ -drive if=none,file=/home/joeyli/iso/openSUSE-MicroOS-DVD-aarch64-Current.iso,id=hd0 -device virtio-blk-device,drive=hd0 \ -drive if=none,file=/home/joeyli/qemu-vm/openSUSE-MicroOS-aarch64-efi.qcow2,id=hd1 -device virtio-blk-device,drive=hd1 The above command is failed. I got: qemu-kvm: combined size of system firmware exceeds 8388608 bytes Then I tried to use "-bios" parameter (please note that -bios parameter does NOT support secure boot). THe qemu-kvm command likes this: qemu-kvm \ -m 4096 -cpu host -smp 4 \ -bios /usr/share/qemu/aavmf-aarch64-code.bin \ -net nic,model=virtio -net nic,model=virtio -net bridge,br=br0,helper=/usr/libexec/qemu-bridge-helper \ -drive if=none,file=/home/joeyli/iso/openSUSE-MicroOS-DVD-aarch64-Current.iso,id=hd0 -device virtio-blk-device,drive=hd0 \ -drive if=none,file=/home/joeyli/qemu-vm/openSUSE-MicroOS-aarch64-efi.qcow2,id=hd1 -device virtio-blk-device,drive=hd1 The above command is failed. I got: qemu-kvm: -device virtio-blk-device,drive=hd0: No 'virtio-bus' bus found for device 'virtio-blk-device' Simply said, I don't know how to install a aarch64 VM with a qemu graphics window. Because this issue is about graphics. I think that using serial console installation is NOT useful for creating a environment for debugging.
> I have tried to remove "-vnc :93" and "-serial mon:stdio" qemu parameter and hope to launch the installation process in the qemu graphics window. It will work if you do it like mentioned here: (In reply to Fabian Vogt from comment #18) > (In reply to Stefan Dirsch from comment #14) > > For me it worked to use > > > > qemu-kvm -M virt -m 4096M -bios /usr/share/qemu/aavmf-aarch64-code.bin -cpu > > host -device virtio-gpu-pci ... -device qemu-xhci -device usb-kbd ... > > On my x86_64 hosts I just do > > qemu-system-aarch64 -M virt -cpu cortex-a72 -m 2048 -serial stdio -device > virtio-gpu-pci -device qemu-xhci -device usb-kbd -bios > /usr/share/qemu/aavmf-aarch64-code.bin + whatever storage devices.
(In reply to Fabian Vogt from comment #20) > > I have tried to remove "-vnc :93" and "-serial mon:stdio" qemu parameter and hope to launch the installation process in the qemu graphics window. > > It will work if you do it like mentioned here: > > (In reply to Fabian Vogt from comment #18) > > (In reply to Stefan Dirsch from comment #14) > > > For me it worked to use > > > > > > qemu-kvm -M virt -m 4096M -bios /usr/share/qemu/aavmf-aarch64-code.bin -cpu > > > host -device virtio-gpu-pci ... -device qemu-xhci -device usb-kbd ... > > "qemu-kvm" as a way to launch qemu with the kvm accelerator is not needed and deprecated since a decade. I recommend to use qemu-system-aarch64 -accel kvm Do not spread the use of "qemu-kvm", which ends up in scripts, will break on other architectures, and may be removed in the future.
Hi Fabian, (In reply to Fabian Vogt from comment #20) > > I have tried to remove "-vnc :93" and "-serial mon:stdio" qemu parameter and hope to launch the installation process in the qemu graphics window. > > It will work if you do it like mentioned here: > > (In reply to Fabian Vogt from comment #18) > > (In reply to Stefan Dirsch from comment #14) > > > For me it worked to use > > > > > > qemu-kvm -M virt -m 4096M -bios /usr/share/qemu/aavmf-aarch64-code.bin -cpu > > > host -device virtio-gpu-pci ... -device qemu-xhci -device usb-kbd ... > > > > On my x86_64 hosts I just do > > > > qemu-system-aarch64 -M virt -cpu cortex-a72 -m 2048 -serial stdio -device > > virtio-gpu-pci -device qemu-xhci -device usb-kbd -bios > > /usr/share/qemu/aavmf-aarch64-code.bin + whatever storage devices. Thanks! Using -device virtio-gpu-pci -serial stdio works to me for launching installation process with qemu graphics window. The following command works on my side: qemu-system-aarch64 \ -m 4096 -cpu cortex-a72 -smp 4 -M virt \ -serial stdio -device virtio-gpu-pci -device qemu-xhci -device usb-kbd \ -drive if=pflash,format=raw,readonly,file=/usr/share/qemu/aavmf-aarch64-code.bin \ -drive if=pflash,format=raw,file=/home/joeyli/qemu-vm/openSUSE-MicroOS-aarch64-vars-store.bin \ -net nic,model=virtio -net nic,model=virtio -net bridge,br=br0,helper=/usr/libexec/qemu-bridge-helper \ -drive if=none,file=/home/joeyli/iso/openSUSE-MicroOS-DVD-aarch64-Current.iso,id=hd0 -device virtio-blk-device,drive=hd0 \ -drive if=none,file=/home/joeyli/qemu-vm/openSUSE-MicroOS-aarch64-efi.qcow2,id=hd1 -device virtio-blk-device,drive=hd1
(In reply to Joey Lee from comment #22) > Hi Fabian, > > (In reply to Fabian Vogt from comment #20) > > > I have tried to remove "-vnc :93" and "-serial mon:stdio" qemu parameter and hope to launch the installation process in the qemu graphics window. > > > > It will work if you do it like mentioned here: > > > > (In reply to Fabian Vogt from comment #18) > > > (In reply to Stefan Dirsch from comment #14) > > > > For me it worked to use > > > > > > > > qemu-kvm -M virt -m 4096M -bios /usr/share/qemu/aavmf-aarch64-code.bin -cpu > > > > host -device virtio-gpu-pci ... -device qemu-xhci -device usb-kbd ... > > > > > > On my x86_64 hosts I just do > > > > > > qemu-system-aarch64 -M virt -cpu cortex-a72 -m 2048 -serial stdio -device > > > virtio-gpu-pci -device qemu-xhci -device usb-kbd -bios > > > /usr/share/qemu/aavmf-aarch64-code.bin + whatever storage devices. > > Thanks! Using -device virtio-gpu-pci -serial stdio works to me for launching > installation process with qemu graphics window. The following command works > on my side: > > qemu-system-aarch64 \ > -m 4096 -cpu cortex-a72 -smp 4 -M virt \ Hi Joey, happy it happens to work! Be careful that specifying an exact cpu as you are doing here -cpu cortex-a72 is going to be very dependent on the exact machine you are going to run on. The meaning of -cpu is different than on x86. Does -cpu host work too? Because if it doesn't that is something we really want to fix. Again, that is the supported and recommended option to use for ARM AArch64, I shared the relevant links above. Thanks, C > -serial stdio -device virtio-gpu-pci -device qemu-xhci -device usb-kbd \ > -drive > if=pflash,format=raw,readonly,file=/usr/share/qemu/aavmf-aarch64-code.bin \ > -drive > if=pflash,format=raw,file=/home/joeyli/qemu-vm/openSUSE-MicroOS-aarch64-vars- > store.bin \ > -net nic,model=virtio -net nic,model=virtio -net > bridge,br=br0,helper=/usr/libexec/qemu-bridge-helper \ > -drive > if=none,file=/home/joeyli/iso/openSUSE-MicroOS-DVD-aarch64-Current.iso, > id=hd0 -device virtio-blk-device,drive=hd0 \ > -drive > if=none,file=/home/joeyli/qemu-vm/openSUSE-MicroOS-aarch64-efi.qcow2,id=hd1 > -device virtio-blk-device,drive=hd1
(In reply to Claudio Fontana from comment #23) > Be careful that specifying an exact cpu as you are doing here > > -cpu cortex-a72 > > is going to be very dependent on the exact machine you are going to run on. > The meaning of -cpu is different than on x86. Not sure what you mean by that. > Does -cpu host work too? Because if it doesn't that is something we really > want to fix. Without KVM there's no -cpu host: > qemu-system-aarch64 -cpu host -M virt qemu-system-aarch64: unable to find CPU model 'host' > Again, that is the supported and recommended option to use for ARM AArch64, > I shared the relevant links above.
(In reply to Fabian Vogt from comment #24) > (In reply to Claudio Fontana from comment #23) > > Be careful that specifying an exact cpu as you are doing here > > > > -cpu cortex-a72 > > > > is going to be very dependent on the exact machine you are going to run on. > > The meaning of -cpu is different than on x86. > > Not sure what you mean by that. I mean that when using KVM, named cpu models are not really working for ARM. See: https://qemu-project.gitlab.io/qemu/system/arm/cpu-features.html > > > Does -cpu host work too? Because if it doesn't that is something we really > > want to fix. > > Without KVM there's no -cpu host: Yes. What I am saying here is: * when using KVM, do not use qemu-kvm. The proper way to use it is qemu-system-aarch64 -accel kvm . > > > qemu-system-aarch64 -cpu host -M virt > qemu-system-aarch64: unable to find CPU model 'host' > > > Again, that is the supported and recommended option to use for ARM AArch64, > > I shared the relevant links above. On the original request, I don't see anything here to do. We know that virtio-gpu-pci works, and we see it working both with KVM and TCG. I continue to recommend to test on actual hardware with KVM, and not with TCG, because that is what is actually supported by us for customers running actual workloads. I do not see anything to do here, can we close?
(In reply to Claudio Fontana from comment #25) > (In reply to Fabian Vogt from comment #24) > > (In reply to Claudio Fontana from comment #23) > > > Be careful that specifying an exact cpu as you are doing here > > > > > > -cpu cortex-a72 > > > > > > is going to be very dependent on the exact machine you are going to run on. > > > The meaning of -cpu is different than on x86. > > > > Not sure what you mean by that. > > I mean that when using KVM, named cpu models are not really working for ARM. > > See: https://qemu-project.gitlab.io/qemu/system/arm/cpu-features.html > > > > Does -cpu host work too? Because if it doesn't that is something we really > > > want to fix. > > > > Without KVM there's no -cpu host: > > Yes. What I am saying here is: > > * when using KVM, do not use qemu-kvm. The proper way to use it is > qemu-system-aarch64 -accel kvm . Without kvm, you must specifiy some -cpu. The default cpu is cortex-a15 which does not have AArch64. > > > qemu-system-aarch64 -cpu host -M virt > > qemu-system-aarch64: unable to find CPU model 'host' > > > > > Again, that is the supported and recommended option to use for ARM AArch64, > > > I shared the relevant links above. > > On the original request, I don't see anything here to do. > > We know that virtio-gpu-pci works, and we see it working both with KVM and > TCG. > > I continue to recommend to test on actual hardware with KVM, and not with > TCG, because that is what is actually supported by us for customers running > actual workloads. > > I do not see anything to do here, can we close? The bug report is about efifb not working with qemu-system-aarch64.
(In reply to Fabian Vogt from comment #26) > (In reply to Claudio Fontana from comment #25) > > I do not see anything to do here, can we close? > > The bug report is about efifb not working with qemu-system-aarch64. > Right, so... (In reply to Fabian Vogt from comment #7) > So a question for the virtualization team (qemu + ovmf): What's the right > controller to use to get this to work? I guess ramfb might work but it's too > limited to be usable in practice. ...I may still be missing something (not an ARM guy), but my impression is that it's either virtio-gpu-pci or nothing (and I'm talking about upstream). And I still don't think I understand what you meant with this: (In reply to Fabian Vogt from comment #7) > That explains it. Looking at the EDK II source, the driver for > virtio-gpu-pci does not expose a linear framebuffer, only virtio-vga does > (https://github.com/tianocore/edk2/blob/ > 952b5cf94c8727b65e04d3d507c0134743be2a66/OvmfPkg/Virtio10Dxe/Virtio10. > c#L1029). virtio-vga is not available in qemu-system-aarch64 though. What is it that we're missing?
(In reply to Dario Faggioli from comment #27) > (In reply to Fabian Vogt from comment #26) > > (In reply to Claudio Fontana from comment #25) > > > I do not see anything to do here, can we close? > > > > The bug report is about efifb not working with qemu-system-aarch64. > > > Right, so... > > (In reply to Fabian Vogt from comment #7) > > So a question for the virtualization team (qemu + ovmf): What's the right > > controller to use to get this to work? I guess ramfb might work but it's too > > limited to be usable in practice. > > ...I may still be missing something (not an ARM guy), but my impression is > that it's either virtio-gpu-pci or nothing (and I'm talking about upstream). There's also ramfb, but that's not really usable in practice. > And I still don't think I understand what you meant with this: > > (In reply to Fabian Vogt from comment #7) > > That explains it. Looking at the EDK II source, the driver for > > virtio-gpu-pci does not expose a linear framebuffer, only virtio-vga does > > (https://github.com/tianocore/edk2/blob/ > > 952b5cf94c8727b65e04d3d507c0134743be2a66/OvmfPkg/Virtio10Dxe/Virtio10. > > c#L1029). virtio-vga is not available in qemu-system-aarch64 though. > > What is it that we're missing? I guess either virtio-vga support for aarch64 or somehow support for a linear framebuffer with virtio-gpu-pci.
(In reply to Fabian Vogt from comment #28) > (In reply to Dario Faggioli from comment #27) > > (In reply to Fabian Vogt from comment #26) > > > (In reply to Claudio Fontana from comment #25) > > > > I do not see anything to do here, can we close? > > > > > > The bug report is about efifb not working with qemu-system-aarch64. > > > > > Right, so... > > > > (In reply to Fabian Vogt from comment #7) > > > So a question for the virtualization team (qemu + ovmf): What's the right > > > controller to use to get this to work? I guess ramfb might work but it's too > > > limited to be usable in practice. > > > > ...I may still be missing something (not an ARM guy), but my impression is > > that it's either virtio-gpu-pci or nothing (and I'm talking about upstream). > > There's also ramfb, but that's not really usable in practice. > > > And I still don't think I understand what you meant with this: > > > > (In reply to Fabian Vogt from comment #7) > > > That explains it. Looking at the EDK II source, the driver for > > > virtio-gpu-pci does not expose a linear framebuffer, only virtio-vga does > > > (https://github.com/tianocore/edk2/blob/ > > > 952b5cf94c8727b65e04d3d507c0134743be2a66/OvmfPkg/Virtio10Dxe/Virtio10. > > > c#L1029). virtio-vga is not available in qemu-system-aarch64 though. > > > > What is it that we're missing? > > I guess either virtio-vga support for aarch64 or somehow support for a > linear framebuffer with virtio-gpu-pci. unfortunately I think if ramfb is not enough, we do not have any other option available for AArch64 at the moment. Seems that this has been a missing feature on AArch64 for a while, see for example also this bug from 2019 that has a good description: https://bugzilla.redhat.com/show_bug.cgi?id=1679680 I would have to close this as FEATURE for now, since making progress on this would require implementing a new feature for ARM upstream.
(In reply to Claudio Fontana from comment #29) > (In reply to Fabian Vogt from comment #28) > > (In reply to Dario Faggioli from comment #27) > > > (In reply to Fabian Vogt from comment #26) > > > > (In reply to Claudio Fontana from comment #25) > > > > > I do not see anything to do here, can we close? > > > > > > > > The bug report is about efifb not working with qemu-system-aarch64. > > > > > > > Right, so... > > > > > > (In reply to Fabian Vogt from comment #7) > > > > So a question for the virtualization team (qemu + ovmf): What's the right > > > > controller to use to get this to work? I guess ramfb might work but it's too > > > > limited to be usable in practice. > > > > > > ...I may still be missing something (not an ARM guy), but my impression is > > > that it's either virtio-gpu-pci or nothing (and I'm talking about upstream). > > > > There's also ramfb, but that's not really usable in practice. > > > > > And I still don't think I understand what you meant with this: > > > > > > (In reply to Fabian Vogt from comment #7) > > > > That explains it. Looking at the EDK II source, the driver for > > > > virtio-gpu-pci does not expose a linear framebuffer, only virtio-vga does > > > > (https://github.com/tianocore/edk2/blob/ > > > > 952b5cf94c8727b65e04d3d507c0134743be2a66/OvmfPkg/Virtio10Dxe/Virtio10. > > > > c#L1029). virtio-vga is not available in qemu-system-aarch64 though. > > > > > > What is it that we're missing? > > > > I guess either virtio-vga support for aarch64 or somehow support for a > > linear framebuffer with virtio-gpu-pci. > > unfortunately I think if ramfb is not enough, we do not have any other > option available for AArch64 at the moment. > > Seems that this has been a missing feature on AArch64 for a while, see for > example also this bug from 2019 that has a good description: > > https://bugzilla.redhat.com/show_bug.cgi?id=1679680 > > I would have to close this as FEATURE for now, since making progress on this > would require implementing a new feature for ARM upstream. So where do we go from here? JIRA ticket?
Hi Thomas, I have installed a MicroOS guest success. But I got problem when debugging kernel. I have cross-compiler kernel with aarch64 on my build server, then I tried to run "make modules_install" in MicroOS guest but I got "Read-only file system" because root partition is read-only on MicroOS. Then I tried to use "transactional-update run make modules_install", but it shows "No rule to make target modules_install". Do you know how to install a kernel from a kernel source tree on MicroOS? Thanks a lot!
(In reply to Fabian Vogt from comment #30) > (In reply to Claudio Fontana from comment #29) > > (In reply to Fabian Vogt from comment #28) > > > (In reply to Dario Faggioli from comment #27) > > > > (In reply to Fabian Vogt from comment #26) > > > > > (In reply to Claudio Fontana from comment #25) > > > > > > I do not see anything to do here, can we close? > > > > > > > > > > The bug report is about efifb not working with qemu-system-aarch64. > > > > > > > > > Right, so... > > > > > > > > (In reply to Fabian Vogt from comment #7) > > > > > So a question for the virtualization team (qemu + ovmf): What's the right > > > > > controller to use to get this to work? I guess ramfb might work but it's too > > > > > limited to be usable in practice. > > > > > > > > ...I may still be missing something (not an ARM guy), but my impression is > > > > that it's either virtio-gpu-pci or nothing (and I'm talking about upstream). > > > > > > There's also ramfb, but that's not really usable in practice. > > > > > > > And I still don't think I understand what you meant with this: > > > > > > > > (In reply to Fabian Vogt from comment #7) > > > > > That explains it. Looking at the EDK II source, the driver for > > > > > virtio-gpu-pci does not expose a linear framebuffer, only virtio-vga does > > > > > (https://github.com/tianocore/edk2/blob/ > > > > > 952b5cf94c8727b65e04d3d507c0134743be2a66/OvmfPkg/Virtio10Dxe/Virtio10. > > > > > c#L1029). virtio-vga is not available in qemu-system-aarch64 though. > > > > > > > > What is it that we're missing? > > > > > > I guess either virtio-vga support for aarch64 or somehow support for a > > > linear framebuffer with virtio-gpu-pci. > > > > unfortunately I think if ramfb is not enough, we do not have any other > > option available for AArch64 at the moment. > > > > Seems that this has been a missing feature on AArch64 for a while, see for > > example also this bug from 2019 that has a good description: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1679680 > > > > I would have to close this as FEATURE for now, since making progress on this > > would require implementing a new feature for ARM upstream. > > So where do we go from here? JIRA ticket? Tf this is something that we need to implement for the products, yes. Adding a few words about the more general context and the actual use case is likely to help.
I'll file a separate bug for the specific issue here, which is that drm support is missing in the initrd for encryption prompts. (It's not fixed, setting status to RESOLVED FEATURE again) (In reply to Joey Lee from comment #31) > Hi Thomas, > > I have installed a MicroOS guest success. But I got problem when debugging > kernel. Any reason to use MicroOS specifically? Using TW should be fine here. > I have cross-compiler kernel with aarch64 on my build server, then I tried > to run "make modules_install" in MicroOS guest but I got "Read-only file > system" because root partition is read-only on MicroOS. > > Then I tried to use "transactional-update run make modules_install", but it > shows "No rule to make target modules_install". > > Do you know how to install a kernel from a kernel source tree on MicroOS? The easiest option is probably to install microos-devel-tools and use microos-rw to make the snapshot read-write temporarily. > Thanks a lot!
(In reply to Fabian Vogt from comment #33) > I'll file a separate bug for the specific issue here, which is that drm > support is missing in the initrd for encryption prompts. Done: bug 1224404