Thank you Radim for the answer! There are indeed some differences between those systems in KVM modules parameters; I've updated the gist with all those details : https://gist.github.com/jbguerraz/faef292b48b2d0106d8d96ba0ddd943c With a focus on differences between the two FC25 systems, we get : - /sys/module/kvm_intel/parameters/enable_shadow_vmcs is set to Y on the not working one - /sys/module/kvm_intel/parameters/pml is set to Y on the not working one Tried to use the "-no-hpet" flag but, no luck, same problem. I've finally used my best google-fu but I'm sadly lost with the "check TPR", maybe you could give me a hint about that ? 2017-04-13 16:44 GMT+02:00 Radim Krčmář <rkrcmar@xxxxxxxxxx>: > 2017-04-13 15:05+0100, Stefan Hajnoczi: >> On Wed, Apr 12, 2017 at 09:11:12PM +0200, Jean Baptiste Guerraz wrote: >> > Hello, >> > >> > We're facing an issue with a Windows guest VM which runs quite well on >> > a laptop (Fedora 25 - Core I7 4720HQ - >> > https://www.asus.com/Notebooks/N551JX/specifications/ ) but not on 2 >> > different servers (one Debian 8 on >> > https://documentation.online.net/en/dedicated-server/offers/2015/server-dedibox-pro-2015-gen2#server_dedibox_pro_2015_gen2 >> > - and one Fedora 25 on >> > https://documentation.online.net/en/dedicated-server/offers/2016/server-dedibox-md-2016#server_dedibox_md_2016) > > Interesting, is there some consistent difference between > > grep . /sys/module/kvm*/parameters/* > > on those systems? > >> > qemu-system-x86 7420 [000] 28829.151599: kvm:kvm_mmio: mmio read len >> > 4 gpa 0xfed000f0 val 0x5e3c5955 >> >> This is the physical address range of the HPET (timer). > > Right, disabling HPET is worth a shot. :) > >> > If one of you have an idea about how to dig further, that would be super :) >> >> I looked at a few of the interrupts that were injected. An interrupt is >> interrupt delivered every 15 milliseconds. They were immediately >> acknowledged by the interrupt handler function inside the guest. >> >> This just looks like a running guest that's doing no I/O to me. > > It had two vector 47 interrupts earlier and those only got delivered > after TPR was lowered, so the problem could a bug in KVM's TPR handling, > which only allows vector 209 after some point? > >> Can anyone else spot something suspicious that indicates 100% guest CPU >> consumption? > > It seems to be reading HPET in a tight loop. No idea why, though. > > So far, I'd compare kvm parameters, disable HPET, and check TPR, to see > where that goes, > > thanks.
