Hi, Thanks for your response!
On 08/02/2017 11:42 PM, Michael Tokarev wrote: > The thing is that there are no changes in +deb9u1 which > can lead to anything like that, at all. Yes, I noticed that myself, which makes it really weird. > Unless, which is > also a possibility, there's a bug in my build environment > (I use regular sbuild stretch chroot for that). Does qemu embed anything from its Build-Dependencies so that the change was perhaps not in qemu but in something else and +deb9u1 just happened to pick it up because it was compiled later? > 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. Well, to be honest I was surprised to see all of these CPU flags specified by libvirt. I would have expected it to just have Skylake-Client as the cpu, plus potentially one or two flags to support the IOMMU passthrough of devices, but not these many. > But your environment is quite a bit unusual, In some sense yes. But in some other sense it isn't that weird. I set it up in the following way: - Stretch system (while it was still frozen but close to the release) - used virt-manager to create a new VM. Selected Windows 10 as OS, then before installing the OS I made sure that the processor was not the Host CPU, but a Skylake (by selecting it from the CPU list provided by libvirt); I did this to make sure I could at a later point in time migrate the VM to a different system without having to reactive Windows - after installing the QEMU Guest Agent on the OS I changed the hard disks + NIC to use virtio (for performance) - later on after installing the aforementioned PCIe card in the computer itself, I just added a PCI Host Device in virt-manager to the VM image That causes libvirt to run qemu with all of these options. > Did you try to restart libvirtd to start with If I remember correctly I did a reboot of the computer to check that the BIOS settings were still all OK. (i.e. VT-x and VT-d enabled) But I'm not completely sure about that. I might not get to that before Monday, but I'll try the following next: - first of all I'll try to upgrade qemu and then reboot the entire system before restarting the VM (to make sure it's not some caching issue you mentioned) - recompile both 1:2.8+dfsg-6 and 1:2.8+dfsg-6+deb9u1 in a clean Stretch build environment and see if I can reproduce the issue with self-built packages I'll update this bug report once I know more. Regards, Christian
