On Thu, Oct 12, 2017 at 03:11:31PM -0700, Mike Larkin wrote: > On Thu, Oct 12, 2017 at 10:36:42PM +0200, Michał Koc wrote: > > > > > On Thu, Oct 12, 2017 at 01:23:36PM +0200, Michał Koc wrote: > > > > On Sun, Oct 08, 2017 at 11:59:52PM +0200, Oliver Marugg wrote: > > > > > > On 7 Oct 2017, at 22:01, Mike Larkin wrote: > > > > > > > > > > > > > On Sat, Oct 07, 2017 at 02:19:58PM +0200, Oliver Marugg wrote: > > > > > > > > Just to add a 4th situation of hangs: Login via proxmox > > > > > > > > (pve)/kvm > > > > > > > > serial > > > > > > > > console (via noVNC), login successful: Vm guest in pve hangs, > > > > > > > > cpu > > > > > > > > usage at > > > > > > > > above 102%. Only way is to hard stop the Vm guest. -oliver > > > > > > > > > > > > > > > sounds like a kvm bug. Ask your provider to investigate the host > > > > > > > side > > > > > > > when this > > > > > > > happens. > > > > > > Thanks Mike, will do so. The proxmox guys have also the idea that > > > > > > it could > > > > > > be a bug in kvm hypervisor (which is the hypervisor part for > > > > > > proxmox) and > > > > > > will affect OpenBSD since 4.9, they wrote me in their public forum. > > > > > > As far > > > > > > as I understood they do not know what OpenBSD needs in kvm or > > > > > > what/where > > > > > > should be fixed in kvm run OpenBSD without that freezes. > > > > > > > > > > > > -oliver > > > > > >From what I read, the cpu spins to 100%, which means somewhere on > > > > > >the host it's > > > > > likely spinning also. Start with systrace/ptrace/ktrace/whatever on > > > > > the host > > > > > qemu-kvm and go from there... > > > > > > > > > > -ml > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > it looks like the cpu process of kvm (CPU 0/KVM) is issuing 1500+ of > > > > ioctl(15, KVM_RUN, 0) per second while running OpenBSD 6.2 guest. > > > > > > > What CPU profile is being presented to the OpenBSD guest? > > > > > > I've seen things like this happen when a vCPU is claimed to have > > > monitor/mwait > > > support, but the hypervisor implements those as NOPs, which just results > > > in > > > spinning like this. > > > > > > In short - try changing the type of CPU presented to the guest and see if > > > that > > > changes behaviour. At least then you'll have more data points to work > > > with. > > > > > > -ml > > > > Okey, > > How would You disable monitor/mwait support in KVM to be presented to guest > > ? > > > > Well, monitor/mwait was just what I recall contributing to something *like* > this. >
PS, IIRC qemu -cpu ? will show you a list of recognized cpuid flags, from which you can subtract off things you don't want. -ml > If you can determine the guest %rip during each ioctl(vm_run) and give me a > kernel or disassembly I may be able to see if it's something obvious. > > That, or describe a way I can repro this locally. I have a machine I could > put linux on for an evening to test. > > -ml > > > changing CPU to pentium or setting <feature policy='disable' > > name='monitor'/> does not actually change anything in scope of host cpu > > utilization.... > > > > BR > > M.K. > > > > > > > > > > > In case of linux guest the process issues about 15 of those ioctls per > > > > second. > > > > > > > > In any case I cannot make openbsd to starve KVM host cpu. OpenBSD uses > > > > at > > > > most(when idle) 7% of cpu. > > > > > > > > My versions: > > > > - OpenBSD 6.2 amd64 > > > > - KVM 2.8.1 > > > > > > > > BR > > > > M.K. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
