On Thu, Jan 24, 2019 at 01:17:01PM +0000, mabi wrote: > Hi, > > I am testing VMM/VMD on an OpenBSD 6.4 host with an OpenBSD 6.4 as guest OS > and noticed that on a fresh installation the CPU seems to be all the time > 100% busy dealing with interrupts. Here is the relevant line from "top": > > CPU states: 0.0% user, 0.0% nice, 0.0% sys, 0.0% spin, 100% intr, 0.0% > idle > > And the output of "vmstat" looks like this: > vmstat 1 > procs memory page disk traps cpu > r s avm fre flt re pi po fr sr sd0 int sys cs us sy id > 1 32 15M 668M 4 0 0 0 0 0 0 102 12 14 0 99 1 > 0 33 15M 668M 12 0 0 0 0 0 0 210 41 41 0 98 2 > 0 33 15M 668M 7 0 0 0 0 0 0 207 36 33 0 99 1 > 0 33 15M 668M 7 0 0 0 0 0 0 210 37 36 0 98 2 > 0 33 15M 668M 7 0 0 0 0 0 0 209 37 36 0 100 0 > > The "Interrupts" column in the output of "systat" looks like this: > > Interrupts > 276 total > virtio0 > virtio1 > 15 virtio2 > com0 > 133 clock > 128 rtc > > This VM has nothing running yet, the only thing I did is to disable sndiod > and change this kernel parameter so that the time in the VM is more accurate: > > kern.timecounter.hardware=tsc > > So my question here would be if this 100% interrupt usage is normal under an > OpenBSD VM? or is there something I might be doing wrong? > > Below I pasted the "dmesg" output of my VM. Let me know if more details are > required. > > Regards, > Mabi > > > OpenBSD 6.4 (GENERIC) #3: Thu Dec 20 18:31:57 CET 2018 > [email protected]:/usr/src/sys/arch/amd64/compile/GENERIC > real mem = 1056956416 (1007MB) > avail mem = 1015816192 (968MB) > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf1950 (10 entries) > bios0: vendor SeaBIOS version "1.11.0p0-OpenBSD-vmm" date 01/01/2011 > bios0: OpenBSD VMM > acpi at bios0 not configured > cpu0 at mainbus0: (uniprocessor) > cpu0: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz, 2396.03 MHz, 06-2c-02 > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,PCLMUL,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,AES,HV,NXE,PAGE1GB,LONG,LAHF,ITSC,MELTDOWN > cpu0: 256KB 64b/line 8-way L2 cache > cpu0: smt 0, core 0, package 0 > pvbus0 at mainbus0: OpenBSD > pci0 at mainbus0 bus 0 > pchb0 at pci0 dev 0 function 0 "OpenBSD VMM Host" rev 0x00 > virtio0 at pci0 dev 1 function 0 "Qumranet Virtio RNG" rev 0x00 > viornd0 at virtio0 > virtio0: irq 3 > virtio1 at pci0 dev 2 function 0 "Qumranet Virtio Storage" rev 0x00 > vioblk0 at virtio1 > scsibus1 at vioblk0: 2 targets > sd0 at scsibus1 targ 0 lun 0: <VirtIO, Block Device, > SCSI3 0/direct fixed > sd0: 51200MB, 512 bytes/sector, 104857600 sectors > virtio1: irq 5 > virtio2 at pci0 dev 3 function 0 "Qumranet Virtio Network" rev 0x00 > vio0 at virtio2: address fe:e1:bb:ff:ff:ff > virtio2: irq 6 > virtio3 at pci0 dev 4 function 0 "OpenBSD VMM Control" rev 0x00 > vmmci0 at virtio3 > virtio3: irq 7 > isa0 at mainbus0 > isadma0 at isa0 > com0 at isa0 port 0x3f8/8 irq 4: ns16450, no fifo > com0: console > vscsi0 at root > scsibus2 at vscsi0: 256 targets > softraid0 at root > scsibus3 at softraid0: 256 targets > root on sd0a (2c1a48e720407786.a) swap on sd0b dump on sd0b > >
I believe this to be an accounting error and has been discussed on the lists several times. -ml
