26.07.2017 18:49, Christian Seiler wrote: > Package: qemu-system-x86 > Version: 1:2.8+dfsg-6+deb9u1 > Severity: important > X-Debbugs-Cc: secur...@debian.org > > Dear maintainers, dear security team, > > after performing the security upgrade to 1:2.8+dfsg-6+deb9u1 a virtual > machine (managed via libvirt) does not start anymore. > > Underlying CPU is an Intel Kaby Lake Core i7-7700. VT-x and VT-d are > enabled in the BIOS. Kernel cmdline has intel_iommu=on. Latest > microcode update is installed. > > KVM configuration: Machine of guest is set to pc-i440fx-2.8, CPU is set > to Skylake-Client. A PCIe framegrabber card (in x16 slot, but card is > x4 or x8, I don't remember exactly) is passed through to the guest. > > With 1:2.8+dfsg-6 the guest boots just fine. > > With 1:2.8+dfsg-6+deb9u1 the guest doesn't start properly. In the > journal I can find the following message every time I try to start the > guest: > > libvirtd[964]: ...: 984: error : x86FeatureInData:780 : internal error: > unknown CPU feature __kvm_hv_spinlocks > libvirtd[964]: ...: 964: error : qemuMonitorIO:695 : internal error: End of > file from qemu monitor > > To get this working again I downgraded qemu-kvm, qemu-system-common > and qemu-system-x86 back to 1:2.8+dfsg-6.
Only qemu-system-x86 is relevant here, the rest is not. The thing is that there are no changes in +deb9u1 which can lead to anything like that, at all. Unless, which is also a possibility, there's a bug in my build environment (I use regular sbuild stretch chroot for that). I've no idea what can cause this, and where this 'feature' come from to start with - it smells like some libvirt thing, but I'm not sure. At least there's no such string in qemu itself, there is, however, hv-spinlocks feature in qemu, and it definitely hasn't changed in +deb9u1. Hmm.. But your environment is quite a bit unusual, I highly doubt I for one will be able to replicate it. Did you try to restart libvirtd to start with - maybe some cached data went out of sync after upgrade? Thanks, /mjt
