Gerd, the patch to fix this was sent to 8.2.0.z but not 8.2.1. Any reason for that or a mistake?
Oh, Mirek moved to 8.2.1 and you already agreed. Ignore my request, please.
QA_ACK, please?
@Yash or Martin: can pm_Ack this?
Sanity test against standalone ramfb device: packages used: qemu-kvm-4.2.0-25.module+el8.2.1+6985+9fd9d514.x86_64 seabios-bin-1.13.0-1.module+el8.2.0+5520+4e5817f3.noarch edk2-ovmf-20190829git37eef91017ad-9.el8.noarch kernel-4.18.0-193.7.1.el8_2.x86_64(host & rhel VM) Test against rhel 8.2 VM: qemu cmd used: /usr/libexec/qemu-kvm \ ... -machine pc-q35-rhel8.2.0,accel=kvm,usb=off,dump-guest-core=off \ ... -vnc 0.0.0.0:0 \ -device ramfb,id=video0 \ ... When VM start, I'm able to interact with grub of VM, but dmesg won't output to vnc console during VM boot. Inside VM, I don't see a fb device presented: #cat /proc/fb (return nothing) And there is no fb0 under /dev/ Switch to uefi, qemu cmd used: /usr/libexec/qemu-kvm \ ... -blockdev '{"driver":"file","filename":"/usr/share/edk2/ovmf/OVMF_CODE.secboot.fd","node-name":"libvirt-pflash0-storage","auto-read-only":true,"discard":"unmap"}' \ -blockdev '{"node-name":"libvirt-pflash0-format","read-only":true,"driver":"raw","file":"libvirt-pflash0-storage"}' \ -blockdev '{"driver":"file","filename":"/var/lib/libvirt/qemu/nvram/ramfb-rhel-uefi_VARS.fd","node-name":"libvirt-pflash1-storage","auto-read-only":true,"discard":"unmap"}' \ -blockdev '{"node-name":"libvirt-pflash1-format","read-only":false,"driver":"raw","file":"libvirt-pflash1-storage"}' \ -machine pc-q35-rhel8.2.0,accel=kvm,usb=off,smm=on,dump-guest-core=off,pflash0=libvirt-pflash0-format,pflash1=libvirt-pflash1-format \ ... -vnc 0.0.0.0:1 \ -device ramfb,id=video0 \ When VM start, I'm able to interact with grub of VM, and dmesg also output to vnc console during VM boot. Inside VM, I can also see a fb device presented: cat /proc/fb 0 EFI VGA And there is fb0 under /dev/ Gerd, is this difference ( no fb device in seabios vs has fb device in uefi) expected? BR/ Zhiyi
> [ seabios ] > When VM start, I'm able to interact with grub of VM, but dmesg won't output > to vnc console during VM boot. > Inside VM, I don't see a fb device presented: > #cat /proc/fb > (return nothing) > And there is no fb0 under /dev/ > Gerd, is this difference ( no fb device in seabios vs has fb device in uefi) > expected? When booted using bios linux uses vga text mode (vgacon) by default which doesn't work with ramfb. When explicitly asking for graphics mode via kernel command line linux will use vesafb and the framebuffer console (fbcon) instead, which does work. Try "vga=ask" to check out your options, or try "vga=0x344" for 1024x768. When booted with efi using the framebuffer (efifb) and fbcon is the default, so it works out-of-the-box there.
(In reply to Gerd Hoffmann from comment #16) > > [ seabios ] > > When VM start, I'm able to interact with grub of VM, but dmesg won't output > > to vnc console during VM boot. > > Inside VM, I don't see a fb device presented: > > #cat /proc/fb > > (return nothing) > > And there is no fb0 under /dev/ > > > Gerd, is this difference ( no fb device in seabios vs has fb device in uefi) > > expected? > > When booted using bios linux uses vga text mode (vgacon) by default which > doesn't > work with ramfb. When explicitly asking for graphics mode via kernel > command line > linux will use vesafb and the framebuffer console (fbcon) instead, which > does work. > > Try "vga=ask" to check out your options, or try "vga=0x344" for 1024x768. Yes, with vga=ask and pick 0x344 for resolution, I can see console and find fb device within VM now, thanks! BR/ Zhiyi
Test against windows 10 2004 VM: qemu cmd used: /usr/libexec/qemu-kvm \ ... -machine pc-q35-rhel8.2.0,accel=kvm,usb=off,dump-guest-core=off \ ... -vnc 0.0.0.0:0 \ -device ramfb,id=video0 \ ... When VM start, I can see boot logo of windows and windows can enter desktop. Check the display device inside Display Manager, I don't see any display adaptor, but I can see monitor attach to VM Switch to uefi, qemu cmd used: /usr/libexec/qemu-kvm \ ... -blockdev '{"driver":"file","filename":"/usr/share/edk2/ovmf/OVMF_CODE.secboot.fd","node-name":"libvirt-pflash0-storage","auto-read-only":true,"discard":"unmap"}' \ -blockdev '{"node-name":"libvirt-pflash0-format","read-only":true,"driver":"raw","file":"libvirt-pflash0-storage"}' \ -blockdev '{"driver":"file","filename":"/var/lib/libvirt/qemu/nvram/ramfb-rhel-uefi_VARS.fd","node-name":"libvirt-pflash1-storage","auto-read-only":true,"discard":"unmap"}' \ -blockdev '{"node-name":"libvirt-pflash1-format","read-only":false,"driver":"raw","file":"libvirt-pflash1-storage"}' \ -machine pc-q35-rhel8.2.0,accel=kvm,usb=off,smm=on,dump-guest-core=off,pflash0=libvirt-pflash0-format,pflash1=libvirt-pflash1-format \ ... -vnc 0.0.0.0:1 \ -device ramfb,id=video0 \ I get same result as seabios
Test ramfb + intel vgpu with rhel 8.2 VM: qemu cmd used: /usr/libexec/qemu-kvm \ ... -machine pc-q35-rhel8.2.0,accel=kvm,usb=off,dump-guest-core=off \ ... -vnc 0.0.0.0:0 \ -display egl-headless,rendernode=/dev/dri/renderD128 \ -device vfio-pci-nohotplug,id=hostdev0,sysfsdev=/sys/bus/mdev/devices/653ee6b0-c00b-4384-9f73-52cbc20ac903,display=on,bus=pci.7,addr=0x0,ramfb=on \ ... intel vgpu I used is multi-user.target vm kernel cmdline configured: BOOT_IMAGE=(hd0,msdos1)/vmlinuz-4.18.0-193.9.1.el8_2.x86_64 root=/dev/mapper/rhel_bootp--73--226--220-root ro modprobe.blacklist=nouveau crashkernel=auto resume=/dev/mapper/rhel_bootp--73--226--220-swap rd.lvm.lv=rhel_bootp-73-226-220/root rd.lvm.lv=rhel_bootp-73-226-220/swap console=tty console=ttyS0,115200 vga=0x344 When VM is configured in multi-user.target mode, before kernel load i915 driver dmesg will output to ramfb console, after i915 driver is loaded, dmesg will output to vgpu device and I can interact with vgpu console smoothly. When VM is configured in graphical.target mode, I can enter gnome desktop without any error. Desktop interaction is also very smooth. Check the fb device inside VM, there are two fb device and i915 is the primary fb device.
Test ramfb + intel vgpu with windows 10 2004 VM: qemu cmd used: /usr/libexec/qemu-kvm \ ... -vnc 0.0.0.0:0 \ -display egl-headless,rendernode=/dev/dri/renderD128 \ -device vfio-pci-nohotplug,id=hostdev0,sysfsdev=/sys/bus/mdev/devices/653ee6b0-c00b-4384-9f73-52cbc20ac903,display=on,bus=pci.4,addr=0x0,ramfb=on \ -set device.hostdev0.x-igd-opregion=on \ ... During VM boot, I can see windows boot icon and VM will boot to desktop. After installing intel vgpu driver inside VM and reboot, windows vm can still show boot icon and boot to desktop using intel vGPU. Inside VM, there is only one display and intel vgpu can be found. Interact with vm desktop is smooth too.
Hi Gerd, Please check comment 15 - comment 20, can we verify this bug base on the result? If yes, is it ok to just test ramfb with vgpu device instead of standalone device? For pure display user cases, I think vga device is better than a standalone ramfb device. Thanks! BR/ Zhiyi
BTW, I have also checked ramfb with nvidia vGPU. For rhel 8.2 VM, multi-user.target mode works perfectly. The desktop mode also works good, but if I try to switch between tty and desktop(by press ctrl + alt + F2/F1), there is no console login output, this may caused by nvidia vGPU doesn't provide any emulated head and ramfb doesn't support modesetting.. For windows 10 VM, ramfb + nvidia vGPU indeed works very well
(In reply to Guo, Zhiyi from comment #21) > Hi Gerd, > > Please check comment 15 - comment 20, can we verify this bug base on the > result? Yes, looks all good. > If yes, is it ok to just test ramfb with vgpu device instead of > standalone device? For pure display user cases, I think vga device is better > than a standalone ramfb device. If vga is available (which is not the case on aarch64), then yes, vga is the better choice for sure. And, yes, ramfb+vgpu is the most important use case (it avoid alot of the problems you have when using qxl for boot display). I'd still suggest to not drop standalone ramfb testing completely, but it surely can be low priority.
(In reply to Guo, Zhiyi from comment #22) > BTW, I have also checked ramfb with nvidia vGPU. For rhel 8.2 VM, > multi-user.target mode works perfectly. The desktop mode also works good, > but if I try to switch between tty and desktop(by press ctrl + alt + F2/F1), > there is no console login output, this may caused by nvidia vGPU doesn't > provide any emulated head and ramfb doesn't support modesetting.. Once the nvidia driver is loaded ramfb is not used any more. So if nvidia doesn't support the framebuffer console (it did not last time I checked, quite a while ago) then yes, no text console terminals for you.
Gerd, thanks for confirmation! Mark this bug verified. BR/ Zhiyi
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2020:3172