Created attachment 1487026 [details] This is what I saw when booting fc29 as guest os. Nothing further was hapening for half an hour. Description of problem: Version-Release number of selected component (if applicable): Since kernel-4.18.8-200.fc28.x86_64 I am unable to boot a guest os in qemu/kvm. I tried with various versions of linux. How reproducible: Always, however, I was able to boot a Centos4 system, but it reported some IRQ#11 problem in /var/log/messages causing the network interface to not working. The suggested fix to provide "acpi=off" did not help. The problem also occurs in Fedora29 after the latest update. Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Created attachment 1487034 [details] /var/log/messages from CentOS-4 system
Does it boot if you bang on the keyboard? One ongoing problem is blocking on entropy. There are patches in the kernel to work around this but it still requires correct settings in qemu.
(In reply to Laura Abbott from comment #2) > Does it boot if you bang on the keyboard? One ongoing problem is blocking on > entropy. There are patches in the kernel to work around this but it still > requires correct settings in qemu. No difference. It did work perfectly in previous version kernel-4.18.7-200.fc28.x86_64.
Created attachment 1487241 [details] Boot attempt of an RH73 client (Not RHEL, the old one from before fedora).
Booting various Fedora live images (27, 28, 29) in gnome-boxes fails since kernel-4.18.8-200.fc28 running on the virtual host. An installed Fedora 28 guest does not reach the graphical login when the host kernel is kernel-4.18.7-200.fc28 or later. After downgrading the host kernel e.g. to kernel-4.18.5-200.fc28, the virtual Fedora 28 guest boots again as expected. The same issue is observed when running the latest Ubuntu 18.10 live image. Changing the virtual video device of an already installed virtual guest to QXL makes no difference. Likewise, it does not make a difference whether a GNOME on Wayland or a GNOME on X session is run on the virtual guest. Currently, it seems to be impossible to run a (recent) Fedora virtual guest on a Fedora 28 virtual host when using gnome-boxes. Since kernel-4.18.8-200.fc28 contains important security fixes, using an older kernel is no option.
There were several KVM fixes that came into 4.18.9. Can you try that or 4.18.10 which is going to be filed in bodhi?
(In reply to Laura Abbott from comment #6) > There were several KVM fixes that came into 4.18.9. Can you try that or > 4.18.10 which is going to be filed in bodhi? Already running 4.18.9 for several days and it still has the problem. 4.18.7 works OK 4.18.8 broken 4.18.9 broken 4.18.10 unavailable
Can you give some more information about your setup. How much memory are you giving the guest, what video is in use (boxes defaults to spice). What is the host graphics? Can you run the guest outside of boxes? I am having difficulty reproducing here with 4.18.9 as the host kernel.
Created attachment 1487784 [details] lshw host system.
Created attachment 1487793 [details] libvirt/qemu configuration files, gzipped tar file.
(In reply to Justin M. Forbes from comment #8) > Can you give some more information about your setup. How much memory are you > giving the guest, what video is in use (boxes defaults to spice). What is > the host graphics? Can you run the guest outside of boxes? I am having > difficulty reproducing here with 4.18.9 as the host kernel. What do you mean "run the guest outside of boxes"? By the way I use XFCE.
No improvement for these kernel packages running on the host: - kernel-4.18.10-200.fc28 - kernel-4.19.0-0.rc5.git0.1.fc30
(In reply to Villy Kruse from comment #11) > What do you mean "run the guest outside of boxes"? By the way I use XFCE. Sorry, that was a different comment using boxes. So, looking at your config files, it seems that these are all 32bit guests failing? Have you tried a 64bit guest just to see if it is something limited to running 32bit guests?
(In reply to Justin M. Forbes from comment #13) > (In reply to Villy Kruse from comment #11) > > > What do you mean "run the guest outside of boxes"? By the way I use XFCE. > > Sorry, that was a different comment using boxes. So, looking at your config > files, it seems that these are all 32bit guests failing? Have you tried a > 64bit guest just to see if it is something limited to running 32bit guests? No. Both 32bit and 64bit guests. The "experiment" is using TianoCore aka edk2 for uefi boot. That one doesn't even come as far as the boot prompt.
(In reply to Joachim Frieben from comment #12) > No improvement for these kernel packages running on the host: > - kernel-4.18.10-200.fc28 > - kernel-4.19.0-0.rc5.git0.1.fc30 Can you attach your system config as well? I am trying to find some sort of common ground as to what is happening here.
(In reply to Villy Kruse from comment #14) > (In reply to Justin M. Forbes from comment #13) > > (In reply to Villy Kruse from comment #11) > > > > > What do you mean "run the guest outside of boxes"? By the way I use XFCE. > > > > Sorry, that was a different comment using boxes. So, looking at your config > > files, it seems that these are all 32bit guests failing? Have you tried a > > 64bit guest just to see if it is something limited to running 32bit guests? > > No. Both 32bit and 64bit guests. The "experiment" is using TianoCore aka > edk2 for uefi boot. That one doesn't even come as far as the boot prompt. Just to double check, booted kernel-4.18.7 and created a new virtual machine with xfce-28 64bit. It fails to boot in 4.18.10, which I meanwhile found in your build system. Actually, it boots, but gets stuck in initrd.
(In reply to Justin M. Forbes from comment #15) I am running various Fedora/Mint/Ubuntu live images with the standard configuration provided by gnome-boxes/qemu. The default video device is virtio-vga which excludes the possibility of adding "nomodeset" to the virtual guest's kernel options. Host and guest systems are of type x86_64. There seem to have been bad changes introduced into kernel 4.18.8 compared to 4.18.7 related to KVM.
(In reply to Joachim Frieben from comment #17) > (In reply to Justin M. Forbes from comment #15) > I am running various Fedora/Mint/Ubuntu live images with the standard > configuration provided by gnome-boxes/qemu. The default video device is > virtio-vga which excludes the possibility of adding "nomodeset" to the > virtual guest's kernel options. Host and guest systems are of type x86_64. > There seem to have been bad changes introduced into kernel 4.18.8 compared > to 4.18.7 related to KVM. Right, but what CPU model are you using, and what video on the host? I am trying to see if there is a correlation of CPU features that are problematic, as I cannot reproduce on modern i7 CPUs.
(In reply to Justin M. Forbes from comment #18) The host system is a Lenovo ThinkPad T400 with an Intel P8400 Core 2 Duo CPU, 8 GB of system memory, and an AMD HD 3470 video device.
Interesting that they are both Intel Wolfdale CPUs, and fairly old. I am wondering if Intel hasn't updated the microcode for those yet to deal with the new Spectre/Meltdown issues, and the kvm changes for L1TD are causing the issue here
(In reply to Justin M. Forbes from comment #20) It is correct that the Linux kernel can use the recent microcode extensions for Core i processors released by Intel in order to mitigate recently discovered vulnerabilities but as far as I remember these extensions are optional but by no means mandatory. Maybe the relevant changes do assume recent CPU features which would be a bug. In the output of 'dmesg', a number of virtio devices such as virtio_blk, virtio_console, or virtio_net return error -2 upon initialization. Furthermore, virtio_gpu produces another error message, namely: "[drm: virtio_gpu_driver_load.cold5 [virtio_gpu]] *ERROR* failed to find virt queues"
I was experiencing this issue (Windows 2008 guest running on HP Compaq dc5800, qemu/kvm) and came across this Linux mailing list report: "Core2 issue with 4.18.8+ kernel" (https://www.spinics.net/lists/kvm/msg175634.html). Applying the patch suggested "[v2] KVM: x86: fix L1TF's MMIO GFN calculation" (https://patchwork.kernel.org/patch/10614795/), which is queued for inclusion, solved the problem for me.
Thanks for the pointer. There's some fuzz when applying the patch so I'm a little wary of picking it up as is just in case there's more work needed (I'm not eager to cause more regressions). If someone from the KVM side can confirm it's okay for applying to 4.18.x, I'll bring it in otherwise we can see if it gets picked up with the next stable batch.
(In reply to Laura Abbott from comment #23) It seems that the fix was not included in 4.18.12, and indeed, kernel-4.18.12-200.fc28 does not show any improvement. A patched Fedora kernel build would be helpful to verify that the patch is working properly.
(In reply to Joachim Frieben from comment #24) > (In reply to Laura Abbott from comment #23) > It seems that the fix was not included in 4.18.12, and indeed, > kernel-4.18.12-200.fc28 does not show any improvement. A patched Fedora > kernel build would be helpful to verify that the patch is working properly. I would say that as well.
(In reply to Villy Kruse from comment #25) > (In reply to Joachim Frieben from comment #24) > > (In reply to Laura Abbott from comment #23) > > It seems that the fix was not included in 4.18.12, and indeed, > > kernel-4.18.12-200.fc28 does not show any improvement. A patched Fedora > > kernel build would be helpful to verify that the patch is working properly. > > I would say that as well. Same for me.
The patch appears to have been added to 4.19-rc7 (https://lwn.net/Articles/767784/ and https://lkml.org/lkml/2018/10/5/293), so my guess is that it won't be included in the 4.18.x series.
The patch is queued for the 4.18.14 stable release.
Strangely enough, Oracle VirtualBox is not affected by this problem.
(In reply to Villy Kruse from comment #29) I would say it just does not use KVM. Oracle VM VirtualBox exists on various platforms and comes with its own kernel module just like there used to exist a KQEMU kernel module which could be used on systems even without hardware virtualization extensions.
I am unable to boot a guest os in qemu/kvm too, since kernel-4.18.8 on arch linux host. when boot is failed, the message below is displayed. virtio_blk virtio1: device uses modern interface but not have VIRTIO_F_VERSION_1 And when kernel-lts-4.14.72, I am unable to boot, too. I can boot when kernel-4.18.7 or kernel-lts-4.14.69.
I can boot guest os in qemu/kvm on kernel-4.18.14 and kernel-4.14.76-1-lts. thanks you, very much.
kernel-4.18.14 indeed fixed the problem. I can boot 32bit and 64bin linux clients without problems. By the way, why is status still "New"?