* [Qemu-devel] Why is SeaBIOS used with -kernel?
@ 2016-03-19 20:31 Richard W.M. Jones
2016-03-21 7:58 ` Gerd Hoffmann
2016-03-31 9:21 ` Stefan Hajnoczi
0 siblings, 2 replies; 55+ messages in thread
From: Richard W.M. Jones @ 2016-03-19 20:31 UTC (permalink / raw)
To: qemu-devel
[-- Attachment #1: Type: text/plain, Size: 940 bytes --]
I've been analyzing the libguestfs appliance[1] boot time. See
attached file, especially the end of it.
About 50% of the boot time is because of SeaBIOS.
I'm using the qemu -kernel option. I understand that the kernel needs
some BIOS features, eg. video stuff, E820. But kvmtool comes with a
really minimal BIOS that implements a tiny number of calls[2] and is
far faster than SeaBIOS.
Is there something I'm missing, or for Linux + -kernel could we use a
much simpler BIOS?
Rich.
[1] http://libguestfs.org/guestfs-internals.1.html
[2] https://git.kernel.org/cgit/linux/kernel/git/will/kvmtool.git/tree/x86
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
[-- Attachment #2: analysis.txt --]
[-- Type: text/plain, Size: 95924 bytes --]
Linux moo.home.annexia.org 4.4.4-301.fc23.x86_64 #1 SMP Fri Mar 4 17:42:42 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
model name : Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz
Warming up the libguestfs cache ...
Running the tests in 2 passes ...
pass 1: 461 events collected in 2225687928 ns
pass 2: 461 events collected in 2245359074 ns
pass 0
number of events collected 461
elapsed time 2225687928 ns
#0: +97056 [trace] "launch"
#1: +99375 [trace] "version"
#2: +102941 [trace] "version = <struct guestfs_version = major: 1, minor: 33, release: 15, extra: , >"
#3: +104764 [trace] "get_backend"
#4: +106283 [trace] "get_backend = "direct""
#5: +107087 [library] "launch: program=boot-analysis"
#6: +107817 [library] "launch: version=1.33.15"
#7: +108501 [library] "launch: backend registered: unix"
#8: +109093 [library] "launch: backend registered: uml"
#9: +109563 [library] "launch: backend registered: libvirt"
#10: +109974 [library] "launch: backend registered: direct"
#11: +110351 [library] "launch: backend=direct"
#12: +110837 [library] "launch: tmpdir=/home/rjones/d/libguestfs/tmp/libguestfs8sCP3g"
#13: +130042 [library] "launch: umask=0002"
#14: +130664 [library] "launch: euid=1000"
#15: +141444 [trace] "get_backend_setting "force_tcg""
#16: +144353 [trace] "get_backend_setting = NULL (error)"
#17: +149190 [trace] "get_cachedir"
#18: +150661 [trace] "get_cachedir = "/home/rjones/d/libguestfs/tmp""
#19: +160857 [library] "[00000ms] begin building supermin appliance"
#20: +161663 [library] "[00000ms] run supermin"
#21: +163979 [library] "command: run: /usr/bin/supermin"
#22: +164362 [library] "command: run: \ --build"
#23: +164687 [library] "command: run: \ --verbose"
#24: +164988 [library] "command: run: \ --if-newer"
#25: +165486 [library] "command: run: \ --lock /home/rjones/d/libguestfs/tmp/.guestfs-1000/lock"
#26: +166046 [library] "command: run: \ --copy-kernel"
#27: +166438 [library] "command: run: \ -f ext2"
#28: +166825 [library] "command: run: \ --host-cpu x86_64"
#29: +167210 [library] "command: run: \ /home/rjones/d/libguestfs/appliance/supermin.d"
#30: +167639 [library] "command: run: \ -o /home/rjones/d/libguestfs/tmp/.guestfs-1000/appliance.d"
#31: +7977059 [appliance] "supermin: version: 5.1.15"
#32: +7977825 [appliance] "supermin: rpm: detected RPM version 4.13"
#33: +7978229 [appliance] "supermin: package handler: fedora/rpm"
#34: +7978451 [appliance] "supermin: acquiring lock on /home/rjones/d/libguestfs/tmp/.guestfs-1000/lock"
#35: +7980242 [appliance] "supermin: if-newer: output does not need rebuilding"
#36: +10380455 [library] "[00010ms] finished building supermin appliance"
#37: +10400123 [library] "[00010ms] begin testing qemu features"
#38: +10402506 [library] "command: run: /usr/bin/qemu-kvm"
#39: +10402987 [library] "command: run: \ -display none"
#40: +10403324 [library] "command: run: \ -help"
#41: +104765465 [library] "command: run: /usr/bin/qemu-kvm"
#42: +104766714 [library] "command: run: \ -display none"
#43: +104767288 [library] "command: run: \ -version"
#44: +202653873 [library] "qemu version 2.5"
#45: +202657614 [library] "command: run: /usr/bin/qemu-kvm"
#46: +202658496 [library] "command: run: \ -display none"
#47: +202659149 [library] "command: run: \ -machine accel=kvm:tcg"
#48: +202659767 [library] "command: run: \ -device ?"
#49: +298757574 [trace] "get_sockdir"
#50: +298763200 [trace] "get_sockdir = "/run/user/1000""
#51: +299096021 [library] "[00298ms] finished testing qemu features"
#52: +299106806 [trace] "get_backend_setting "gdb""
#53: +299112199 [trace] "get_backend_setting = NULL (error)"
#54: +300843518 [appliance] "[00299ms] /usr/bin/qemu-kvm \"
#55: +300845906 [appliance] " -global virtio-blk-pci.scsi=off \"
#56: +300846753 [appliance] " -nodefconfig \"
#57: +300847651 [appliance] " -enable-fips \"
#58: +300848437 [appliance] " -nodefaults \"
#59: +300849245 [appliance] " -display none \"
#60: +300850119 [appliance] " -machine accel=kvm:tcg \"
#61: +300850938 [appliance] " -cpu host \"
#62: +300851744 [appliance] " -m 500 \"
#63: +300852472 [appliance] " -no-reboot \"
#64: +300853218 [appliance] " -rtc driftfix=slew \"
#65: +300853946 [appliance] " -no-hpet \"
#66: +300854764 [appliance] " -global kvm-pit.lost_tick_policy=discard \"
#67: +300855667 [appliance] " -kernel /home/rjones/d/libguestfs/tmp/.guestfs-1000/appliance.d/kernel \"
#68: +300856630 [appliance] " -initrd /home/rjones/d/libguestfs/tmp/.guestfs-1000/appliance.d/initrd \"
#69: +300857530 [appliance] " -device virtio-scsi-pci,id=scsi \"
#70: +300858666 [appliance] " -drive file=/home/rjones/d/libguestfs/tmp/libguestfs8sCP3g/devnull1,cache=writeback,id=hd0,if=none \"
#71: +300859526 [appliance] " -device scsi-hd,drive=hd0 \"
#72: +300860403 [appliance] " -drive file=/home/rjones/d/libguestfs/tmp/.guestfs-1000/appliance.d/root,snapshot=on,id=appliance,cache=unsafe,if=none \"
#73: +300861333 [appliance] " -device scsi-hd,drive=appliance \"
#74: +300862214 [appliance] " -device virtio-serial-pci \"
#75: +300862972 [appliance] " -serial stdio \"
#76: +300863725 [appliance] " -device sga \"
#77: +300864509 [appliance] " -chardev socket,path=/run/user/1000/libguestfsHISXnh/guestfsd.sock,id=channel0 \"
#78: +300865352 [appliance] " -device virtserialport,chardev=channel0,name=org.libguestfs.channel.0 \"
#79: +300866237 [appliance] " -append 'panic=1 console=ttyS0 udevtimeout=6000 udev.event-timeout=6000 no_timer_check acpi=off printk.time=1 cgroup_disable=memory root=/dev/sdb selinux=0 guestfs_verbose=1 TERM=xterm-256color guestfs_boot_analysis=1'"
#80: +394940831 [appliance] "WARNING: Image format was not specified for '/home/rjones/d/libguestfs/tmp/libguestfs8sCP3g/devnull1' and probing guessed raw."
#81: +394943216 [appliance] " Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted."
#82: +394944138 [appliance] " Specify the 'raw' format explicitly to remove the restrictions."
#83: +460731351 [appliance] "\x1b[1;256r\x1b[256;256H\x1b[6n"
#84: +720512029 [appliance] "Google, Inc."
#85: +720514529 [appliance] "Serial Graphics Adapter 06/19/15"
#86: +720516269 [appliance] "SGABIOS $Id: sgabios.S 8 2010-04-22 00:03:40Z nlaredo $ (mockbuild@) Fri Jun 19 00:52:18 UTC 2015"
#87: +720518119 [appliance] "Term: 80x24"
#88: +720519624 [appliance] "4 0"
#89: +720521032 [appliance] "\x1b[2J\x0dSeaBIOS (version 1.8.2-20150714_191134-)"
#90: +831045679 [appliance] "\x0dBooting from ROM..."
#91: +1484676723 [appliance] "\x0dProbing EDD (edd=off to disable)... ok"
#92: +1484683728 [appliance] "\x1b[2J[ 0.000000] Initializing cgroup subsys cpuset"
#93: +1564390068 [appliance] "[ 0.000000] Initializing cgroup subsys cpu"
#94: +1564391677 [appliance] "[ 0.000000] Initializing cgroup subsys cpuacct"
#95: +1564392523 [appliance] "[ 0.000000] Linux version 4.4.4-301.fc23.x86_64 (mockbuild@bkernel02.phx2.fedoraproject.org) (gcc version 5.3.1 20151207 (Red Hat 5.3.1-2) (GCC) ) #1 SMP Fri Mar 4 17:42:42 UTC 2016"
#96: +1565551586 [appliance] "[ 0.000000] Command line: panic=1 console=ttyS0 udevtimeout=6000 udev.event-timeout=6000 no_timer_check acpi=off printk.time=1 cgroup_disable=memory root=/dev/sdb selinux=0 guestfs_verbose=1 TERM=xterm-256color guestfs_boot_analysis=1"
#97: +1566686375 [appliance] "[ 0.000000] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256"
#98: +1567821975 [appliance] "[ 0.000000] x86/fpu: Supporting XSAVE feature 0x01: 'x87 floating point registers'"
#99: +1567824023 [appliance] "[ 0.000000] x86/fpu: Supporting XSAVE feature 0x02: 'SSE registers'"
#100: +1568960944 [appliance] "[ 0.000000] x86/fpu: Supporting XSAVE feature 0x04: 'AVX registers'"
#101: +1568962466 [appliance] "[ 0.000000] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format."
#102: +1570098436 [appliance] "[ 0.000000] x86/fpu: Using 'eager' FPU context switches."
#103: +1570099889 [appliance] "[ 0.000000] e820: BIOS-provided physical RAM map:"
#104: +1570100738 [appliance] "[ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009f7ff] usable"
#105: +1571236219 [appliance] "[ 0.000000] BIOS-e820: [mem 0x000000000009f800-0x000000000009ffff] reserved"
#106: +1571237650 [appliance] "[ 0.000000] BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved"
#107: +1571238489 [appliance] "[ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000001f3dffff] usable"
#108: +1572375870 [appliance] "[ 0.000000] BIOS-e820: [mem 0x000000001f3e0000-0x000000001f3fffff] reserved"
#109: +1572377379 [appliance] "[ 0.000000] BIOS-e820: [mem 0x00000000feffc000-0x00000000feffffff] reserved"
#110: +1573511176 [appliance] "[ 0.000000] BIOS-e820: [mem 0x00000000fffc0000-0x00000000ffffffff] reserved"
#111: +1573512531 [appliance] "[ 0.000000] NX (Execute Disable) protection: active"
#112: +1573513372 [appliance] "[ 0.000000] SMBIOS 2.8 present."
#113: +1573514154 [appliance] "[ 0.000000] Hypervisor detected: KVM"
#114: +1574648609 [appliance] "[ 0.000000] e820: last_pfn = 0x1f3e0 max_arch_pfn = 0x400000000"
#115: +1574650066 [appliance] "[ 0.000000] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WC UC- WT "
#116: +1574650874 [appliance] "[ 0.000000] found SMP MP-table at [mem 0x000f64d0-0x000f64df] mapped at [ffff8800000f64d0]"
#117: +1575784326 [appliance] "[ 0.000000] Using GB pages for direct mapping"
#118: +1575785725 [appliance] "[ 0.000000] RAMDISK: [mem 0x1f38a000-0x1f3dffff]"
#119: +1575786474 [appliance] "[ 0.000000] No NUMA configuration found"
#120: +1576912443 [appliance] "[ 0.000000] Faking a node at [mem 0x0000000000000000-0x000000001f3dffff]"
#121: +1576913522 [appliance] "[ 0.000000] NODE_DATA(0) allocated [mem 0x1f378000-0x1f389fff]"
#122: +1576914317 [appliance] "[ 0.000000] kvm-clock: Using msrs 4b564d01 and 4b564d00"
#123: +1578047938 [appliance] "[ 0.000000] kvm-clock: cpu 0, msr 0:1f368001, primary cpu clock"
#124: +1578049370 [appliance] "[ 0.000000] kvm-clock: using sched offset of 1121123956 cycles"
#125: +1578050134 [appliance] "[ 0.000000] clocksource: kvm-clock: mask: 0xffffffffffffffff max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns"
#126: +1579184946 [appliance] "[ 0.000000] Zone ranges:"
#127: +1579186293 [appliance] "[ 0.000000] DMA [mem 0x0000000000001000-0x0000000000ffffff]"
#128: +1580320735 [appliance] "[ 0.000000] DMA32 [mem 0x0000000001000000-0x000000001f3dffff]"
#129: +1580322101 [appliance] "[ 0.000000] Normal empty"
#130: +1580323007 [appliance] "[ 0.000000] Movable zone start for each node"
#131: +1580323742 [appliance] "[ 0.000000] Early memory node ranges"
#132: +1581460226 [appliance] "[ 0.000000] node 0: [mem 0x0000000000001000-0x000000000009efff]"
#133: +1581461580 [appliance] "[ 0.000000] node 0: [mem 0x0000000000100000-0x000000001f3dffff]"
#134: +1581462306 [appliance] "[ 0.000000] Initmem setup node 0 [mem 0x0000000000001000-0x000000001f3dffff]"
#135: +1582595748 [appliance] "[ 0.000000] SFI: Simple Firmware Interface v0.81 http://simplefirmware.org"
#136: +1582597114 [appliance] "[ 0.000000] Intel MultiProcessor Specification v1.4"
#137: +1582597993 [appliance] "[ 0.000000] MPTABLE: OEM ID: BOCHSCPU"
#138: +1583731540 [appliance] "[ 0.000000] MPTABLE: Product ID: 0.1 "
#139: +1583732917 [appliance] "[ 0.000000] MPTABLE: APIC at: 0xFEE00000"
#140: +1583733687 [appliance] "[ 0.000000] Processor #0 (Bootup-CPU)"
#141: +1583734450 [appliance] "[ 0.000000] IOAPIC[0]: apic_id 0, version 17, address 0xfec00000, GSI 0-23"
#142: +1584872191 [appliance] "[ 0.000000] Processors: 1"
#143: +1584874323 [appliance] "[ 0.000000] smpboot: Allowing 1 CPUs, 0 hotplug CPUs"
#144: +1584875790 [appliance] "[ 0.000000] PM: Registered nosave memory: [mem 0x00000000-0x00000fff]"
#145: +1586012051 [appliance] "[ 0.000000] PM: Registered nosave memory: [mem 0x0009f000-0x0009ffff]"
#146: +1586013496 [appliance] "[ 0.000000] PM: Registered nosave memory: [mem 0x000a0000-0x000effff]"
#147: +1586014349 [appliance] "[ 0.000000] PM: Registered nosave memory: [mem 0x000f0000-0x000fffff]"
#148: +1587150643 [appliance] "[ 0.000000] e820: [mem 0x1f400000-0xfeffbfff] available for PCI devices"
#149: +1587151970 [appliance] "[ 0.000000] Booting paravirtualized kernel on KVM"
#150: +1587152833 [appliance] "[ 0.000000] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1910969940391419 ns"
#151: +1588288872 [appliance] "[ 0.000000] setup_percpu: NR_CPUS:1024 nr_cpumask_bits:1 nr_cpu_ids:1 nr_node_ids:1"
#152: +1589427436 [appliance] "[ 0.000000] PERCPU: Embedded 34 pages/cpu @ffff88001f000000 s98712 r8192 d32360 u2097152"
#153: +1589428809 [appliance] "[ 0.000000] KVM setup async PF for cpu 0"
#154: +1589429686 [appliance] "[ 0.000000] kvm-stealtime: cpu 0, msr 1f00d900"
#155: +1589430443 [appliance] "[ 0.000000] Built 1 zonelists in Node order, mobility grouping on. Total pages: 125849"
#156: +1590574603 [appliance] "[ 0.000000] Policy zone: DMA32"
#157: +1590575949 [appliance] "[ 0.000000] Kernel command line: panic=1 console=ttyS0 udevtimeout=6000 udev.event-timeout=6000 no_timer_check acpi=off printk.time=1 cgroup_disable=memory root=/dev/sdb selinux=0 guestfs_verbose=1 TERM=xterm-256color guestfs_boot_analysis=1"
#158: +1591711162 [appliance] "[ 0.000000] PID hash table entries: 2048 (order: 2, 16384 bytes)"
#159: +1592845248 [appliance] "[ 0.000000] Memory: 485620K/511480K available (7827K kernel code, 1307K rwdata, 3444K rodata, 1528K init, 1544K bss, 25860K reserved, 0K cma-reserved)"
#160: +1593977835 [appliance] "[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1"
#161: +1593979226 [appliance] "[ 0.000000] Hierarchical RCU implementation."
#162: +1593980071 [appliance] "[ 0.000000] \x09Build-time adjustment of leaf fanout to 64."
#163: +1593980907 [appliance] "[ 0.000000] \x09RCU restricting CPUs from NR_CPUS=1024 to nr_cpu_ids=1."
#164: +1595108808 [appliance] "[ 0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=64, nr_cpu_ids=1"
#165: +1595110083 [appliance] "[ 0.000000] NR_IRQS:65792 nr_irqs:256 16"
#166: +1595110857 [appliance] "[ 0.000000] \x09Offload RCU callbacks from all CPUs"
#167: +1596239957 [appliance] "[ 0.000000] \x09Offload RCU callbacks from CPUs: 0."
#168: +1596241288 [appliance] "[ 0.000000] Console: colour *CGA 80x25"
#169: +1596242091 [appliance] "[ 0.000000] console [ttyS0] enabled"
#170: +1597420805 [appliance] "[ 0.000000] tsc: Detected 2593.994 MHz processor"
#171: +1597422043 [appliance] "[ 0.041768] Calibrating delay loop (skipped) preset value.. 5187.98 BogoMIPS (lpj=2593994)"
#172: +1597423841 [appliance] "[ 0.042313] pid_max: default: 32768 minimum: 301"
#173: +1598557713 [appliance] "[ 0.042679] Security Framework initialized"
#174: +1598558889 [appliance] "[ 0.042952] Yama: becoming mindful."
#175: +1598559478 [appliance] "[ 0.043185] SELinux: Disabled at boot."
#176: +1598560031 [appliance] "[ 0.043510] Dentry cache hash table entries: 65536 (order: 7, 524288 bytes)"
#177: +1599665786 [appliance] "[ 0.044066] Inode-cache hash table entries: 32768 (order: 6, 262144 bytes)"
#178: +1599666943 [appliance] "[ 0.044575] Mount-cache hash table entries: 1024 (order: 1, 8192 bytes)"
#179: +1600790774 [appliance] "[ 0.045038] Mountpoint-cache hash table entries: 1024 (order: 1, 8192 bytes)"
#180: +1600792471 [appliance] "[ 0.045637] Initializing cgroup subsys io"
#181: +1601919376 [appliance] "[ 0.045934] Initializing cgroup subsys memory"
#182: +1601920658 [appliance] "[ 0.046373] Disabling memory control group subsystem"
#183: +1601921283 [appliance] "[ 0.046723] Initializing cgroup subsys devices"
#184: +1603045613 [appliance] "[ 0.047045] Initializing cgroup subsys freezer"
#185: +1603046766 [appliance] "[ 0.047361] Initializing cgroup subsys net_cls"
#186: +1603047390 [appliance] "[ 0.047676] Initializing cgroup subsys perf_event"
#187: +1603047967 [appliance] "[ 0.047999] Initializing cgroup subsys net_prio"
#188: +1604162814 [appliance] "[ 0.048320] Initializing cgroup subsys hugetlb"
#189: +1604163939 [appliance] "[ 0.048633] Initializing cgroup subsys pids"
#190: +1605936583 [appliance] "[ 0.049893] mce: CPU supports 10 MCE banks"
#191: +1605937754 [appliance] "[ 0.050217] Last level iTLB entries: 4KB 0, 2MB 0, 4MB 0"
#192: +1605938396 [appliance] "[ 0.050588] Last level dTLB entries: 4KB 0, 2MB 0, 4MB 0, 1GB 0"
#193: +1614982494 [appliance] "[ 0.058961] Freeing SMP alternatives memory: 28K (ffffffff81ec6000 - ffffffff81ecd000)"
#194: +1617579634 [appliance] "[ 0.061573] ftrace: allocating 29522 entries in 116 pages"
#195: +1638502712 [appliance] "[ 0.082440] x2apic enabled"
#196: +1638504244 [appliance] "[ 0.082839] Switched APIC routing to physical x2apic."
#197: +1639917480 [appliance] "[ 0.083884] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1"
#198: +1639918772 [appliance] "[ 0.084315] smpboot: CPU0: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz (family: 0x6, model: 0x3d, stepping: 0x4)"
#199: +1641046836 [appliance] "[ 0.085021] Performance Events: 16-deep LBR, Broadwell events, Intel PMU driver."
#200: +1641047685 [appliance] "[ 0.085559] ... version: 2"
#201: +1641048294 [appliance] "[ 0.085822] ... bit width: 48"
#202: +1641048853 [appliance] "[ 0.086090] ... generic registers: 4"
#203: +1642188713 [appliance] "[ 0.086377] ... value mask: 0000ffffffffffff"
#204: +1642189844 [appliance] "[ 0.086723] ... max period: 000000007fffffff"
#205: +1642190474 [appliance] "[ 0.087064] ... fixed-purpose events: 3"
#206: +1643305181 [appliance] "[ 0.087345] ... event mask: 000000070000000f"
#207: +1643306297 [appliance] "[ 0.088129] x86: Booted up 1 node, 1 CPUs"
#208: +1643306907 [appliance] "[ 0.088403] smpboot: Total of 1 processors activated (5187.98 BogoMIPS)"
#209: +1644417578 [appliance] "[ 0.089054] devtmpfs: initialized"
#210: +1646593775 [appliance] "[ 0.090543] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1911260446275000 ns"
#211: +1646595023 [appliance] "[ 0.091249] atomic64_test: passed for x86-64 platform with CX8 and with SSE"
#212: +1647730726 [appliance] "[ 0.091711] pinctrl core: initialized pinctrl subsystem"
#213: +1647731886 [appliance] "[ 0.092104] RTC time: 20:24:23, date: 03/19/16"
#214: +1647732531 [appliance] "[ 0.092477] NET: Registered protocol family 16"
#215: +1648928412 [appliance] "[ 0.092903] cpuidle: using governor menu"
#216: +1648929587 [appliance] "[ 0.093341] PCI: Using configuration type 1 for base access"
#217: +1650588506 [appliance] "[ 0.094544] ACPI: Interpreter disabled."
#218: +1650589675 [appliance] "[ 0.094872] vgaarb: loaded"
#219: +1650590315 [appliance] "[ 0.095108] SCSI subsystem initialized"
#220: +1650590941 [appliance] "[ 0.095393] usbcore: registered new interface driver usbfs"
#221: +1651720369 [appliance] "[ 0.095775] usbcore: registered new interface driver hub"
#222: +1651722218 [appliance] "[ 0.096140] usbcore: registered new device driver usb"
#223: +1651723272 [appliance] "[ 0.096532] PCI: Probing PCI hardware"
#224: +1651724299 [appliance] "[ 0.096808] PCI host bridge to bus 0000:00"
#225: +1652859284 [appliance] "[ 0.097087] pci_bus 0000:00: root bus resource [io 0x0000-0xffff]"
#226: +1652860564 [appliance] "[ 0.097503] pci_bus 0000:00: root bus resource [mem 0x00000000-0xffffffffff]"
#227: +1653965462 [appliance] "[ 0.097968] pci_bus 0000:00: No busn resource found for root bus, will use [bus 00-ff]"
#228: +1658270908 [appliance] "[ 0.102200] pci 0000:00:01.1: legacy IDE quirk: reg 0x10: [io 0x01f0-0x01f7]"
#229: +1658274529 [appliance] "[ 0.102698] pci 0000:00:01.1: legacy IDE quirk: reg 0x14: [io 0x03f6]"
#230: +1658275180 [appliance] "[ 0.103124] pci 0000:00:01.1: legacy IDE quirk: reg 0x18: [io 0x0170-0x0177]"
#231: +1659394050 [appliance] "[ 0.103610] pci 0000:00:01.1: legacy IDE quirk: reg 0x1c: [io 0x0376]"
#232: +1659395216 [appliance] "[ 0.104369] pci 0000:00:01.3: quirk: [io 0x0600-0x063f] claimed by PIIX4 ACPI"
#233: +1660511396 [appliance] "[ 0.104860] pci 0000:00:01.3: quirk: [io 0x0700-0x070f] claimed by PIIX4 SMB"
#234: +1675343712 [appliance] "[ 0.119267] pci 0000:00:01.0: PIIX/ICH IRQ router [8086:7000]"
#235: +1675345382 [appliance] "[ 0.119850] NetLabel: Initializing"
#236: +1675346034 [appliance] "[ 0.120078] NetLabel: domain hash size = 128"
#237: +1675346592 [appliance] "[ 0.120363] NetLabel: protocols = UNLABELED CIPSOv4"
#238: +1676471989 [appliance] "[ 0.120718] NetLabel: unlabeled traffic allowed by default"
#239: +1676473069 [appliance] "[ 0.121161] clocksource: Switched to clocksource kvm-clock"
#240: +1681957428 [appliance] "[ 0.125895] pnp: PnP ACPI: disabled"
#241: +1681959070 [appliance] "[ 0.126920] NET: Registered protocol family 2"
#242: +1683089205 [appliance] "[ 0.127351] TCP established hash table entries: 4096 (order: 3, 32768 bytes)"
#243: +1683090366 [appliance] "[ 0.127819] TCP bind hash table entries: 4096 (order: 4, 65536 bytes)"
#244: +1684191645 [appliance] "[ 0.128268] TCP: Hash tables configured (established 4096 bind 4096)"
#245: +1684213221 [appliance] "[ 0.128847] UDP hash table entries: 256 (order: 1, 8192 bytes)"
#246: +1684213896 [appliance] "[ 0.129245] UDP-Lite hash table entries: 256 (order: 1, 8192 bytes)"
#247: +1685326502 [appliance] "[ 0.129710] NET: Registered protocol family 1"
#248: +1685327276 [appliance] "[ 0.130010] pci 0000:00:00.0: Limiting direct PCI/PCI transfers"
#249: +1685327639 [appliance] "[ 0.130422] pci 0000:00:01.0: PIIX3: Enabling Passive Release"
#250: +1686452661 [appliance] "[ 0.130811] pci 0000:00:01.0: Activating ISA DMA hang workarounds"
#251: +1686453430 [appliance] "[ 0.131278] Unpacking initramfs..."
#252: +1687767672 [appliance] "[ 0.131724] Freeing initrd memory: 344K (ffff88001f38a000 - ffff88001f3e0000)"
#253: +1687768544 [appliance] "[ 0.132298] platform rtc_cmos: registered platform RTC device (no PNP device found)"
#254: +1689093961 [appliance] "[ 0.133046] futex hash table entries: 256 (order: 2, 16384 bytes)"
#255: +1689094910 [appliance] "[ 0.133496] audit: initializing netlink subsys (disabled)"
#256: +1689095164 [appliance] "[ 0.133857] audit: type=2000 audit(1458419064.040:1): initialized"
#257: +1690217078 [appliance] "[ 0.134465] Initialise system trusted keyring"
#258: +1690217803 [appliance] "[ 0.134816] HugeTLB registered 1 GB page size, pre-allocated 0 pages"
#259: +1690218075 [appliance] "[ 0.135239] HugeTLB registered 2 MB page size, pre-allocated 0 pages"
#260: +1692581624 [appliance] "[ 0.136545] zbud: loaded"
#261: +1692582396 [appliance] "[ 0.136920] VFS: Disk quotas dquot_6.6.0"
#262: +1692582640 [appliance] "[ 0.137212] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes)"
#263: +1693946182 [appliance] "[ 0.137935] Key type big_key registered"
#264: +1695787814 [appliance] "[ 0.139728] NET: Registered protocol family 38"
#265: +1695788638 [appliance] "[ 0.140060] Key type asymmetric registered"
#266: +1695788857 [appliance] "[ 0.140333] Asymmetric key parser 'x509' registered"
#267: +1695789023 [appliance] "[ 0.140691] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 250)"
#268: +1696920526 [appliance] "[ 0.141235] io scheduler noop registered"
#269: +1696921273 [appliance] "[ 0.141496] io scheduler deadline registered"
#270: +1696921450 [appliance] "[ 0.141802] io scheduler cfq registered (default)"
#271: +1698043321 [appliance] "[ 0.142202] pci_hotplug: PCI Hot Plug PCI Core version: 0.5"
#272: +1698044107 [appliance] "[ 0.142565] pciehp: PCI Express Hot Plug Controller Driver version: 0.4"
#273: +1698044318 [appliance] "[ 0.143090] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled"
#274: +1721976002 [appliance] "[ 0.165988] serial8250: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A"
#275: +1723232005 [appliance] "[ 0.167250] Non-volatile memory driver v1.3"
#276: +1723232658 [appliance] "[ 0.167552] Linux agpgart interface v0.103"
#277: +1724587999 [appliance] "[ 0.168570] scsi host0: ata_piix"
#278: +1724588359 [appliance] "[ 0.168848] scsi host1: ata_piix"
#279: +1724588571 [appliance] "[ 0.169094] ata1: PATA max MWDMA2 cmd 0x1f0 ctl 0x3f6 bmdma 0xc060 irq 14"
#280: +1724588819 [appliance] "[ 0.169552] ata2: PATA max MWDMA2 cmd 0x170 ctl 0x376 bmdma 0xc068 irq 15"
#281: +1725686630 [appliance] "[ 0.170205] libphy: Fixed MDIO Bus: probed"
#282: +1725686951 [appliance] "[ 0.170513] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver"
#283: +1726791570 [appliance] "[ 0.170956] ehci-pci: EHCI PCI platform driver"
#284: +1726791847 [appliance] "[ 0.171261] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver"
#285: +1726792035 [appliance] "[ 0.171671] ohci-pci: OHCI PCI platform driver"
#286: +1727900392 [appliance] "[ 0.171971] uhci_hcd: USB Universal Host Controller Interface driver"
#287: +1727900963 [appliance] "[ 0.172423] usbcore: registered new interface driver usbserial"
#288: +1727901137 [appliance] "[ 0.172811] usbcore: registered new interface driver usbserial_generic"
#289: +1729004634 [appliance] "[ 0.173244] usbserial: USB Serial support registered for generic"
#290: +1729004947 [appliance] "[ 0.173656] i8042: PNP: No PS/2 controller found. Probing ports directly."
#291: +1730574973 [appliance] "[ 0.174578] serio: i8042 KBD port at 0x60,0x64 irq 1"
#292: +1730575324 [appliance] "[ 0.174913] serio: i8042 AUX port at 0x60,0x64 irq 12"
#293: +1730575507 [appliance] "[ 0.175461] mousedev: PS/2 mouse device common for all mice"
#294: +1731664398 [appliance] "[ 0.175988] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input0"
#295: +1732942557 [appliance] "[ 0.176945] input: VirtualPS/2 VMware VMMouse as /devices/platform/i8042/serio1/input/input3"
#296: +1732942978 [appliance] "[ 0.177642] input: VirtualPS/2 VMware VMMouse as /devices/platform/i8042/serio1/input/input2"
#297: +1734062409 [appliance] "[ 0.178378] rtc_cmos rtc_cmos: rtc core: registered rtc_cmos as rtc0"
#298: +1734063168 [appliance] "[ 0.178869] rtc_cmos rtc_cmos: alarms up to one day, 114 bytes nvram"
#299: +1735189517 [appliance] "[ 0.179346] device-mapper: uevent: version 1.0.3"
#300: +1735190567 [appliance] "[ 0.179766] device-mapper: ioctl: 4.34.0-ioctl (2015-10-28) initialised: dm-devel@redhat.com"
#301: +1736320716 [appliance] "[ 0.180413] hidraw: raw HID events driver (C) Jiri Kosina"
#302: +1736321604 [appliance] "[ 0.180816] usbcore: registered new interface driver usbhid"
#303: +1736321757 [appliance] "[ 0.181179] usbhid: USB HID core driver"
#304: +1737523474 [appliance] "[ 0.181480] drop_monitor: Initializing network drop monitor service"
#305: +1737524334 [appliance] "[ 0.181957] ip_tables: (C) 2000-2006 Netfilter Core Team"
#306: +1737524569 [appliance] "[ 0.182337] Initializing XFRM netlink socket"
#307: +1738772931 [appliance] "[ 0.182736] NET: Registered protocol family 10"
#308: +1738773755 [appliance] "[ 0.183165] mip6: Mobile IPv6"
#309: +1738773992 [appliance] "[ 0.183365] NET: Registered protocol family 17"
#310: +1738774164 [appliance] "[ 0.183774] microcode: CPU0 sig=0x306d4, pf=0x1, revision=0x1"
#311: +1739910131 [appliance] "[ 0.184192] microcode: Microcode Update Driver: v2.01 <tigran@aivazian.fsnet.co.uk>, Peter Oruba"
#312: +1739910880 [appliance] "[ 0.184768] AVX2 version of gcm_enc/dec engaged."
#313: +1741008523 [appliance] "[ 0.185087] AES CTR mode by8 optimization enabled"
#314: +1757695446 [appliance] "[ 0.201639] registered taskstats version 1"
#315: +1757696640 [appliance] "[ 0.201973] Loading compiled-in X.509 certificates"
#316: +1758907668 [appliance] "[ 0.202865] Loaded X.509 cert 'Fedora kernel signing key: ff671496ff3f386a8ef2031bac2201b2edb4da2a'"
#317: +1758908553 [appliance] "[ 0.203496] zswap: loaded using pool lzo/zbud"
#318: +1758908777 [appliance] "[ 0.203916] Magic number: 8:904:447"
#319: +1760021610 [appliance] "[ 0.204255] rtc_cmos rtc_cmos: setting system clock to 2016-03-19 20:24:23 UTC (1458419063)"
#320: +1883240938 [appliance] "[ 0.327173] Freeing unused kernel memory: 1528K (ffffffff81d48000 - ffffffff81ec6000)"
#321: +1883242402 [appliance] "[ 0.327731] Write protecting the kernel read-only data: 12288k"
#322: +1883242626 [appliance] "[ 0.328225] Freeing unused kernel memory: 352K (ffff8800017a8000 - ffff880001800000)"
#323: +1885922945 [appliance] "[ 0.329893] Freeing unused kernel memory: 652K (ffff880001b5d000 - ffff880001c00000)"
#324: +1885924101 [appliance] "supermin: mounting /proc"
#325: +1885924317 [appliance] "supermin: ext2 mini initrd starting up: 5.1.15 dietlibc"
#326: +1887118652 [appliance] "supermin: cmdline: panic=1 console=ttyS0 udevtimeout=6000 udev.event-timeout=6000 no_timer_check acpi=off printk.time=1 cgroup_disable=memory root=/dev/sdb selinux=0 guestfs_verbose=1 TERM=xterm-256color guestfs_boot_analysis=1"
#327: +1887119552 [appliance] "supermin: uptime: 0.27 0.14"
#328: +1888227367 [appliance] "supermin: mounting /sys"
#329: +1888228166 [appliance] "supermin: internal insmod crc32-pclmul.ko"
#330: +1889562959 [appliance] "supermin: internal insmod crc32c-intel.ko"
#331: +1889563774 [appliance] "supermin: internal insmod crct10dif-pclmul.ko"
#332: +1890663856 [appliance] "supermin: internal insmod crc32.ko"
#333: +1891817677 [appliance] "supermin: internal insmod virtio.ko"
#334: +1893524104 [appliance] "supermin: internal insmod virtio_ring.ko"
#335: +1893524905 [appliance] "supermin: internal insmod virtio_blk.ko"
#336: +1894672466 [appliance] "supermin: internal insmod virtio-rng.ko"
#337: +1895840304 [appliance] "supermin: internal insmod virtio_console.ko"
#338: +1897793718 [appliance] "supermin: internal insmod virtio_net.ko"
#339: +1899046048 [appliance] "supermin: internal insmod virtio_scsi.ko"
#340: +1899046839 [appliance] "supermin: internal insmod virtio_balloon.ko"
#341: +1900146680 [appliance] "supermin: internal insmod virtio_input.ko"
#342: +1901240581 [appliance] "supermin: internal insmod virtio_mmio.ko"
#343: +1902341062 [appliance] "supermin: internal insmod virtio_pci.ko"
#344: +1903450918 [appliance] "[ 0.348355] virtio-pci 0000:00:02.0: PCI->APIC IRQ transform: INT A -> IRQ 10"
#345: +1904553627 [appliance] "[ 0.348868] virtio-pci 0000:00:02.0: virtio_pci: leaving for legacy driver"
#346: +1905855077 [appliance] "[ 0.349838] scsi host2: Virtio SCSI HBA"
#347: +1905855945 [appliance] "[ 0.350266] virtio-pci 0000:00:03.0: PCI->APIC IRQ transform: INT A -> IRQ 11"
#348: +1905856243 [appliance] "[ 0.350772] virtio-pci 0000:00:03.0: virtio_pci: leaving for legacy driver"
#349: +1909907211 [appliance] "[ 0.353855] scsi 2:0:0:0: Direct-Access QEMU QEMU HARDDISK 2.5+ PQ: 0 ANSI: 5"
#350: +1909908494 [appliance] "[ 0.354604] scsi 2:0:1:0: Direct-Access QEMU QEMU HARDDISK 2.5+ PQ: 0 ANSI: 5"
#351: +1925324057 [appliance] "[ 0.369308] sd 2:0:0:0: Attached scsi generic sg0 type 0"
#352: +1925325343 [appliance] "[ 0.369799] sd 2:0:0:0: [sda] 8 512-byte logical blocks: (4.10 kB/4.00 KiB)"
#353: +1926475148 [appliance] "[ 0.370451] sd 2:0:1:0: Attached scsi generic sg1 type 0"
#354: +1926475686 [appliance] "[ 0.370865] sd 2:0:1:0: [sdb] 8388608 512-byte logical blocks: (4.29 GB/4.00 GiB)"
#355: +1926475929 [appliance] "[ 0.371491] sd 2:0:0:0: [sda] Write Protect is off"
#356: +1927603547 [appliance] "[ 0.371876] sd 2:0:1:0: [sdb] Write Protect is off"
#357: +1927604332 [appliance] "[ 0.372256] sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA"
#358: +1928714150 [appliance] "[ 0.372920] sd 2:0:1:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA"
#359: +1930326528 [appliance] "[ 0.374272] Dev sda: unable to read RDB block 8"
#360: +1930327543 [appliance] "[ 0.374606] sda: unable to read partition table"
#361: +1930327968 [appliance] "[ 0.374919] sda: partition table beyond EOD, enabling native capacity"
#362: +1931896087 [appliance] "[ 0.375846] Dev sda: unable to read RDB block 8"
#363: +1931896564 [appliance] "[ 0.376184] sda: unable to read partition table"
#364: +1931896756 [appliance] "[ 0.376484] sda: partition table beyond EOD, truncated"
#365: +1931896971 [appliance] "[ 0.376832] sd 2:0:1:0: [sdb] Attached SCSI disk"
#366: +1932999490 [appliance] "[ 0.377412] sd 2:0:0:0: [sda] Attached SCSI disk"
#367: +1932999869 [appliance] "supermin: internal insmod crc-ccitt.ko"
#368: +1934672292 [appliance] "supermin: internal insmod crc-itu-t.ko"
#369: +1934673332 [appliance] "supermin: internal insmod crc8.ko"
#370: +1935773990 [appliance] "supermin: internal insmod libcrc32c.ko"
#371: +1937440659 [appliance] "supermin: picked /sys/block/sdb/dev as root device"
#372: +1937441654 [appliance] "supermin: creating /dev/root as block special 8:16"
#373: +1937442036 [appliance] "supermin: mounting new root on /root"
#374: +1938727914 [appliance] "[ 0.382706] EXT4-fs (sdb): mounting ext2 file system using the ext4 subsystem"
#375: +1941295363 [appliance] "[ 0.385272] EXT4-fs (sdb): mounted filesystem without journal. Opts: "
#376: +1941296851 [appliance] "supermin: chroot"
#377: +1947912424 [appliance] "Starting /init script ..."
#378: +2026634598 [appliance] "[ 0.470592] random: systemd-tmpfile urandom read with 78 bits of entropy available"
#379: +2027804195 [appliance] "[/usr/lib/tmpfiles.d/journal-nocow.conf:26] Failed to replace specifiers: /var/log/journal/%m"
#380: +2029093160 [appliance] "[/usr/lib/tmpfiles.d/systemd.conf:26] Failed to replace specifiers: /run/log/journal/%m"
#381: +2029093558 [appliance] "[/usr/lib/tmpfiles.d/systemd.conf:28] Failed to replace specifiers: /run/log/journal/%m"
#382: +2029097127 [appliance] "[/usr/lib/tmpfiles.d/systemd.conf:29] Failed to replace specifiers: /run/log/journal/%m"
#383: +2030220164 [appliance] "[/usr/lib/tmpfiles.d/systemd.conf:32] Failed to replace specifiers: /var/log/journal/%m"
#384: +2030220571 [appliance] "[/usr/lib/tmpfiles.d/systemd.conf:33] Failed to replace specifiers: /var/log/journal/%m/system.journal"
#385: +2031595491 [appliance] "[/usr/lib/tmpfiles.d/systemd.conf:37] Failed to replace specifiers: /var/log/journal/%m"
#386: +2031595985 [appliance] "[/usr/lib/tmpfiles.d/systemd.conf:38] Failed to replace specifiers: /var/log/journal/%m"
#387: +2031596233 [appliance] "[/usr/lib/tmpfiles.d/systemd.conf:39] Failed to replace specifiers: /var/log/journal/%m/system.journal"
#388: +2032665234 [appliance] "UDEVD=/usr/lib/systemd/systemd-udevd"
#389: +2035829022 [appliance] "starting version 229"
#390: +2107339884 [appliance] "[ 0.551317] piix4_smbus 0000:00:01.3: PCI->APIC IRQ transform: INT A -> IRQ 9"
#391: +2107341200 [appliance] "[ 0.551842] piix4_smbus 0000:00:01.3: SMBus Host Controller at 0x700, revision 0"
#392: +2127386470 [appliance] "[ 0.571342] intel_rapl: no valid rapl domains found in package 0"
#393: +2163284964 [appliance] "[ 0.607246] random: nonblocking pool is initialized"
#394: +2165510155 [appliance] "[ 0.609480] input: PC Speaker as /devices/platform/pcspkr/input/input4"
#395: +2170014463 [appliance] "+ grep -sq guestfs_network=1 /proc/cmdline"
#396: +2170015881 [appliance] "+ grep -sq guestfs_rescue=1 /proc/cmdline"
#397: +2171577224 [appliance] "+ grep -sq guestfs_noreboot=1 /proc/cmdline"
#398: +2171578171 [appliance] "+ grep -sq guestfs_boot_analysis=1 /proc/cmdline"
#399: +2173013270 [appliance] "+ guestfs_boot_analysis=1"
#400: +2173014095 [appliance] "++ grep -Eo 'guestfs_channel=[^[:space:]]+' /proc/cmdline"
#401: +2173014345 [appliance] "+ eval"
#402: +2174138706 [appliance] "+ grep -sq selinux=1 /proc/cmdline"
#403: +2174139636 [appliance] "+ shopt -s nullglob"
#404: +2174139838 [appliance] "+ for f in '/sys/block/sd*/device/timeout'"
#405: +2175340218 [appliance] "+ echo 300"
#406: +2175341067 [appliance] "+ for f in '/sys/block/sd*/device/timeout'"
#407: +2175341309 [appliance] "+ echo 300"
#408: +2175341449 [appliance] "+ for f in '/sys/block/{h,s,ub,v}d*/queue/scheduler'"
#409: +2175341603 [appliance] "+ echo noop"
#410: +2175341750 [appliance] "+ for f in '/sys/block/{h,s,ub,v}d*/queue/scheduler'"
#411: +2176432219 [appliance] "+ echo noop"
#412: +2176433365 [appliance] "+ shopt -u nullglob"
#413: +2176433657 [appliance] "+ ip addr add 127.0.0.1/8 brd + dev lo scope host"
#414: +2178502546 [appliance] "+ ip link set dev lo up"
#415: +2178504010 [appliance] "+ test '' = 1"
#416: +2178504335 [appliance] "+ mdadm -As --auto=yes --run"
#417: +2182347657 [appliance] "mdadm: No arrays found in config file or automatically"
#418: +2182349001 [appliance] "+ modprobe dm_mod"
#419: +2183606913 [appliance] "+ lvmetad"
#420: +2185979651 [appliance] "+ lvm vgchange -aay --sysinit"
#421: +2189813889 [appliance] " Configuration setting "global/notify_dbus" unknown."
#422: +2189815065 [appliance] " lvmetad is not active yet, using direct activation during sysinit"
#423: +2192653829 [appliance] "+ ldmtool create all"
#424: +2196483642 [appliance] "["
#425: +2196484840 [appliance] "]"
#426: +2196485000 [appliance] "+ test 1 = 1"
#427: +2196485162 [appliance] "+ test 1 '!=' 1"
#428: +2196485325 [appliance] "+ test '' = 1"
#429: +2196485460 [appliance] "+ cmd=guestfsd"
#430: +2197649210 [appliance] "+ test x '!=' x"
#431: +2197649599 [appliance] "+ test 1 = 1"
#432: +2197649736 [appliance] "+ cmd='guestfsd --verbose'"
#433: +2197649891 [appliance] "+ test '' = 1"
#434: +2197650016 [appliance] "+ echo guestfsd --verbose"
#435: +2197650158 [appliance] "guestfsd --verbose"
#436: +2197650282 [appliance] "+ guestfsd --verbose"
#437: +2204508785 [appliance] "trying to open virtio-serial channel '/dev/virtio-ports/org.libguestfs.channel.0'"
#438: +2204510368 [appliance] "udevadm --debug settle"
#439: +2206648777 [appliance] "calling: settle"
#440: +2206652890 [launch_done] "launch done callback"
#441: +2206654841 [library] "recv_from_daemon: received GUESTFS_LAUNCH_FLAG"
#442: +2206658453 [library] "[02206ms] appliance is up"
#443: +2206675099 [trace] "launch = 0"
#444: +2206676517 [trace] "close"
#445: +2206677593 [library] "closing guestfs handle 0x564c2a8cd7a0 (state 2)"
#446: +2206688305 [trace] "internal_autosync"
#447: +2209320588 [appliance] "guestfsd: main_loop: new request, len 0x28"
#448: +2209321513 [appliance] "umount-all: /proc/mounts: fsname=/dev/root dir=/ type=ext2 opts=rw,noatime,block_validity,barrier,user_xattr,acl freq=0 passno=0"
#449: +2209322505 [appliance] "umount-all: /proc/mounts: fsname=/proc dir=/proc type=proc opts=rw,relatime freq=0 passno=0"
#450: +2210463724 [appliance] "umount-all: /proc/mounts: fsname=/sys dir=/sys type=sysfs opts=rw,relatime freq=0 passno=0"
#451: +2210464272 [appliance] "umount-all: /proc/mounts: fsname=tmpfs dir=/run type=tmpfs opts=rw,nosuid,relatime,size=97708k,mode=755 freq=0 passno=0"
#452: +2211579272 [appliance] "umount-all: /proc/mounts: fsname=/dev dir=/dev type=devtmpfs opts=rw,relatime,size=242824k,nr_inodes=60706,mode=755 freq=0 passno=0"
#453: +2214058401 [appliance] "fsync /dev/sda"
#454: +2221147592 [trace] "internal_autosync = 0"
#455: +2221149584 [library] "sending SIGTERM to process 18868"
#456: +2225687281 [close] "close callback"
#457: +2225696157 [library] "command: run: rm"
#458: +2225696982 [library] "command: run: \ -rf /home/rjones/d/libguestfs/tmp/libguestfs8sCP3g"
#459: +2226817341 [library] "command: run: rm"
#460: +2226817932 [library] "command: run: \ -rf /run/user/1000/libguestfsHISXnh"
pass 1
number of events collected 461
elapsed time 2245359074 ns
#0: +88342 [trace] "launch"
#1: +89906 [trace] "version"
#2: +92918 [trace] "version = <struct guestfs_version = major: 1, minor: 33, release: 15, extra: , >"
#3: +94119 [trace] "get_backend"
#4: +95678 [trace] "get_backend = "direct""
#5: +96686 [library] "launch: program=boot-analysis"
#6: +97582 [library] "launch: version=1.33.15"
#7: +98186 [library] "launch: backend registered: unix"
#8: +98632 [library] "launch: backend registered: uml"
#9: +99079 [library] "launch: backend registered: libvirt"
#10: +99536 [library] "launch: backend registered: direct"
#11: +99967 [library] "launch: backend=direct"
#12: +100443 [library] "launch: tmpdir=/home/rjones/d/libguestfs/tmp/libguestfsINdKan"
#13: +118231 [library] "launch: umask=0002"
#14: +118896 [library] "launch: euid=1000"
#15: +127149 [trace] "get_backend_setting "force_tcg""
#16: +130902 [trace] "get_backend_setting = NULL (error)"
#17: +136380 [trace] "get_cachedir"
#18: +137987 [trace] "get_cachedir = "/home/rjones/d/libguestfs/tmp""
#19: +148893 [library] "[00000ms] begin building supermin appliance"
#20: +149957 [library] "[00000ms] run supermin"
#21: +152507 [library] "command: run: /usr/bin/supermin"
#22: +153044 [library] "command: run: \ --build"
#23: +153500 [library] "command: run: \ --verbose"
#24: +154175 [library] "command: run: \ --if-newer"
#25: +154812 [library] "command: run: \ --lock /home/rjones/d/libguestfs/tmp/.guestfs-1000/lock"
#26: +155382 [library] "command: run: \ --copy-kernel"
#27: +155932 [library] "command: run: \ -f ext2"
#28: +156428 [library] "command: run: \ --host-cpu x86_64"
#29: +156961 [library] "command: run: \ /home/rjones/d/libguestfs/appliance/supermin.d"
#30: +157535 [library] "command: run: \ -o /home/rjones/d/libguestfs/tmp/.guestfs-1000/appliance.d"
#31: +7971631 [appliance] "supermin: version: 5.1.15"
#32: +7972754 [appliance] "supermin: rpm: detected RPM version 4.13"
#33: +7973571 [appliance] "supermin: package handler: fedora/rpm"
#34: +7973943 [appliance] "supermin: acquiring lock on /home/rjones/d/libguestfs/tmp/.guestfs-1000/lock"
#35: +7986500 [appliance] "supermin: if-newer: output does not need rebuilding"
#36: +10338598 [library] "[00010ms] finished building supermin appliance"
#37: +10358658 [library] "[00010ms] begin testing qemu features"
#38: +10366255 [library] "command: run: /usr/bin/qemu-kvm"
#39: +10367245 [library] "command: run: \ -display none"
#40: +10367729 [library] "command: run: \ -help"
#41: +105568776 [library] "command: run: /usr/bin/qemu-kvm"
#42: +105569684 [library] "command: run: \ -display none"
#43: +105570201 [library] "command: run: \ -version"
#44: +204912517 [library] "qemu version 2.5"
#45: +204915502 [library] "command: run: /usr/bin/qemu-kvm"
#46: +204916205 [library] "command: run: \ -display none"
#47: +204916761 [library] "command: run: \ -machine accel=kvm:tcg"
#48: +204917388 [library] "command: run: \ -device ?"
#49: +306994830 [trace] "get_sockdir"
#50: +306999078 [trace] "get_sockdir = "/run/user/1000""
#51: +307310294 [library] "[00307ms] finished testing qemu features"
#52: +307320819 [trace] "get_backend_setting "gdb""
#53: +307325324 [trace] "get_backend_setting = NULL (error)"
#54: +309055139 [appliance] "[00307ms] /usr/bin/qemu-kvm \"
#55: +309057848 [appliance] " -global virtio-blk-pci.scsi=off \"
#56: +309058347 [appliance] " -nodefconfig \"
#57: +309058675 [appliance] " -enable-fips \"
#58: +309059006 [appliance] " -nodefaults \"
#59: +309059326 [appliance] " -display none \"
#60: +309059643 [appliance] " -machine accel=kvm:tcg \"
#61: +309061645 [appliance] " -cpu host \"
#62: +309062087 [appliance] " -m 500 \"
#63: +309062434 [appliance] " -no-reboot \"
#64: +309062776 [appliance] " -rtc driftfix=slew \"
#65: +309063058 [appliance] " -no-hpet \"
#66: +309063387 [appliance] " -global kvm-pit.lost_tick_policy=discard \"
#67: +309063768 [appliance] " -kernel /home/rjones/d/libguestfs/tmp/.guestfs-1000/appliance.d/kernel \"
#68: +309064237 [appliance] " -initrd /home/rjones/d/libguestfs/tmp/.guestfs-1000/appliance.d/initrd \"
#69: +309064588 [appliance] " -device virtio-scsi-pci,id=scsi \"
#70: +309064976 [appliance] " -drive file=/home/rjones/d/libguestfs/tmp/libguestfsINdKan/devnull1,cache=writeback,id=hd0,if=none \"
#71: +309065345 [appliance] " -device scsi-hd,drive=hd0 \"
#72: +309065741 [appliance] " -drive file=/home/rjones/d/libguestfs/tmp/.guestfs-1000/appliance.d/root,snapshot=on,id=appliance,cache=unsafe,if=none \"
#73: +309066215 [appliance] " -device scsi-hd,drive=appliance \"
#74: +309066563 [appliance] " -device virtio-serial-pci \"
#75: +309066884 [appliance] " -serial stdio \"
#76: +309067193 [appliance] " -device sga \"
#77: +309067515 [appliance] " -chardev socket,path=/run/user/1000/libguestfsABLpPt/guestfsd.sock,id=channel0 \"
#78: +309067917 [appliance] " -device virtserialport,chardev=channel0,name=org.libguestfs.channel.0 \"
#79: +309068381 [appliance] " -append 'panic=1 console=ttyS0 udevtimeout=6000 udev.event-timeout=6000 no_timer_check acpi=off printk.time=1 cgroup_disable=memory root=/dev/sdb selinux=0 guestfs_verbose=1 TERM=xterm-256color guestfs_boot_analysis=1'"
#80: +403905232 [appliance] "WARNING: Image format was not specified for '/home/rjones/d/libguestfs/tmp/libguestfsINdKan/devnull1' and probing guessed raw."
#81: +403906795 [appliance] " Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted."
#82: +403912252 [appliance] " Specify the 'raw' format explicitly to remove the restrictions."
#83: +472490769 [appliance] "\x1b[1;256r\x1b[256;256H\x1b[6n"
#84: +741331593 [appliance] "Google, Inc."
#85: +741333333 [appliance] "Serial Graphics Adapter 06/19/15"
#86: +741334141 [appliance] "SGABIOS $Id: sgabios.S 8 2010-04-22 00:03:40Z nlaredo $ (mockbuild@) Fri Jun 19 00:52:18 UTC 2015"
#87: +741334803 [appliance] "Term: 80x24"
#88: +741335302 [appliance] "4 0"
#89: +741335821 [appliance] "\x1b[2J\x0dSeaBIOS (version 1.8.2-20150714_191134-)"
#90: +851607087 [appliance] "\x0dBooting from ROM..."
#91: +1498605209 [appliance] "\x0dProbing EDD (edd=off to disable)... ok"
#92: +1498607336 [appliance] "\x1b[2J[ 0.000000] Initializing cgroup subsys cpuset"
#93: +1578556344 [appliance] "[ 0.000000] Initializing cgroup subsys cpu"
#94: +1578557786 [appliance] "[ 0.000000] Initializing cgroup subsys cpuacct"
#95: +1578558207 [appliance] "[ 0.000000] Linux version 4.4.4-301.fc23.x86_64 (mockbuild@bkernel02.phx2.fedoraproject.org) (gcc version 5.3.1 20151207 (Red Hat 5.3.1-2) (GCC) ) #1 SMP Fri Mar 4 17:42:42 UTC 2016"
#96: +1579693960 [appliance] "[ 0.000000] Command line: panic=1 console=ttyS0 udevtimeout=6000 udev.event-timeout=6000 no_timer_check acpi=off printk.time=1 cgroup_disable=memory root=/dev/sdb selinux=0 guestfs_verbose=1 TERM=xterm-256color guestfs_boot_analysis=1"
#97: +1580826954 [appliance] "[ 0.000000] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256"
#98: +1581964769 [appliance] "[ 0.000000] x86/fpu: Supporting XSAVE feature 0x01: 'x87 floating point registers'"
#99: +1581965730 [appliance] "[ 0.000000] x86/fpu: Supporting XSAVE feature 0x02: 'SSE registers'"
#100: +1583100777 [appliance] "[ 0.000000] x86/fpu: Supporting XSAVE feature 0x04: 'AVX registers'"
#101: +1583102010 [appliance] "[ 0.000000] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format."
#102: +1584231905 [appliance] "[ 0.000000] x86/fpu: Using 'eager' FPU context switches."
#103: +1584233043 [appliance] "[ 0.000000] e820: BIOS-provided physical RAM map:"
#104: +1584233511 [appliance] "[ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009f7ff] usable"
#105: +1585367817 [appliance] "[ 0.000000] BIOS-e820: [mem 0x000000000009f800-0x000000000009ffff] reserved"
#106: +1585368724 [appliance] "[ 0.000000] BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved"
#107: +1585369021 [appliance] "[ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000001f3dffff] usable"
#108: +1586503833 [appliance] "[ 0.000000] BIOS-e820: [mem 0x000000001f3e0000-0x000000001f3fffff] reserved"
#109: +1586504760 [appliance] "[ 0.000000] BIOS-e820: [mem 0x00000000feffc000-0x00000000feffffff] reserved"
#110: +1587638208 [appliance] "[ 0.000000] BIOS-e820: [mem 0x00000000fffc0000-0x00000000ffffffff] reserved"
#111: +1587639086 [appliance] "[ 0.000000] NX (Execute Disable) protection: active"
#112: +1587639506 [appliance] "[ 0.000000] SMBIOS 2.8 present."
#113: +1588782924 [appliance] "[ 0.000000] Hypervisor detected: KVM"
#114: +1588783788 [appliance] "[ 0.000000] e820: last_pfn = 0x1f3e0 max_arch_pfn = 0x400000000"
#115: +1588784214 [appliance] "[ 0.000000] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WC UC- WT "
#116: +1589917196 [appliance] "[ 0.000000] found SMP MP-table at [mem 0x000f64d0-0x000f64df] mapped at [ffff8800000f64d0]"
#117: +1589918113 [appliance] "[ 0.000000] Using GB pages for direct mapping"
#118: +1589918530 [appliance] "[ 0.000000] RAMDISK: [mem 0x1f38a000-0x1f3dffff]"
#119: +1591051535 [appliance] "[ 0.000000] No NUMA configuration found"
#120: +1591052734 [appliance] "[ 0.000000] Faking a node at [mem 0x0000000000000000-0x000000001f3dffff]"
#121: +1591053481 [appliance] "[ 0.000000] NODE_DATA(0) allocated [mem 0x1f378000-0x1f389fff]"
#122: +1592188495 [appliance] "[ 0.000000] kvm-clock: Using msrs 4b564d01 and 4b564d00"
#123: +1592190485 [appliance] "[ 0.000000] kvm-clock: cpu 0, msr 0:1f368001, primary cpu clock"
#124: +1592190850 [appliance] "[ 0.000000] kvm-clock: using sched offset of 1126450732 cycles"
#125: +1593323936 [appliance] "[ 0.000000] clocksource: kvm-clock: mask: 0xffffffffffffffff max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns"
#126: +1593335462 [appliance] "[ 0.000000] Zone ranges:"
#127: +1593336036 [appliance] "[ 0.000000] DMA [mem 0x0000000000001000-0x0000000000ffffff]"
#128: +1594471825 [appliance] "[ 0.000000] DMA32 [mem 0x0000000001000000-0x000000001f3dffff]"
#129: +1594472774 [appliance] "[ 0.000000] Normal empty"
#130: +1594473193 [appliance] "[ 0.000000] Movable zone start for each node"
#131: +1595607624 [appliance] "[ 0.000000] Early memory node ranges"
#132: +1595608520 [appliance] "[ 0.000000] node 0: [mem 0x0000000000001000-0x000000000009efff]"
#133: +1595608930 [appliance] "[ 0.000000] node 0: [mem 0x0000000000100000-0x000000001f3dffff]"
#134: +1596757197 [appliance] "[ 0.000000] Initmem setup node 0 [mem 0x0000000000001000-0x000000001f3dffff]"
#135: +1596758218 [appliance] "[ 0.000000] SFI: Simple Firmware Interface v0.81 http://simplefirmware.org"
#136: +1596758558 [appliance] "[ 0.000000] Intel MultiProcessor Specification v1.4"
#137: +1597891709 [appliance] "[ 0.000000] MPTABLE: OEM ID: BOCHSCPU"
#138: +1597892592 [appliance] "[ 0.000000] MPTABLE: Product ID: 0.1 "
#139: +1597892938 [appliance] "[ 0.000000] MPTABLE: APIC at: 0xFEE00000"
#140: +1597893228 [appliance] "[ 0.000000] Processor #0 (Bootup-CPU)"
#141: +1599026696 [appliance] "[ 0.000000] IOAPIC[0]: apic_id 0, version 17, address 0xfec00000, GSI 0-23"
#142: +1599027601 [appliance] "[ 0.000000] Processors: 1"
#143: +1599027967 [appliance] "[ 0.000000] smpboot: Allowing 1 CPUs, 0 hotplug CPUs"
#144: +1599028299 [appliance] "[ 0.000000] PM: Registered nosave memory: [mem 0x00000000-0x00000fff]"
#145: +1600161951 [appliance] "[ 0.000000] PM: Registered nosave memory: [mem 0x0009f000-0x0009ffff]"
#146: +1600162827 [appliance] "[ 0.000000] PM: Registered nosave memory: [mem 0x000a0000-0x000effff]"
#147: +1601296449 [appliance] "[ 0.000000] PM: Registered nosave memory: [mem 0x000f0000-0x000fffff]"
#148: +1601297373 [appliance] "[ 0.000000] e820: [mem 0x1f400000-0xfeffbfff] available for PCI devices"
#149: +1601297697 [appliance] "[ 0.000000] Booting paravirtualized kernel on KVM"
#150: +1602431621 [appliance] "[ 0.000000] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1910969940391419 ns"
#151: +1602432518 [appliance] "[ 0.000000] setup_percpu: NR_CPUS:1024 nr_cpumask_bits:1 nr_cpu_ids:1 nr_node_ids:1"
#152: +1603548781 [appliance] "[ 0.000000] PERCPU: Embedded 34 pages/cpu @ffff88001f000000 s98712 r8192 d32360 u2097152"
#153: +1603549667 [appliance] "[ 0.000000] KVM setup async PF for cpu 0"
#154: +1604698847 [appliance] "[ 0.000000] kvm-stealtime: cpu 0, msr 1f00d900"
#155: +1604699774 [appliance] "[ 0.000000] Built 1 zonelists in Node order, mobility grouping on. Total pages: 125849"
#156: +1604700182 [appliance] "[ 0.000000] Policy zone: DMA32"
#157: +1604700500 [appliance] "[ 0.000000] Kernel command line: panic=1 console=ttyS0 udevtimeout=6000 udev.event-timeout=6000 no_timer_check acpi=off printk.time=1 cgroup_disable=memory root=/dev/sdb selinux=0 guestfs_verbose=1 TERM=xterm-256color guestfs_boot_analysis=1"
#158: +1606970171 [appliance] "[ 0.000000] PID hash table entries: 2048 (order: 2, 16384 bytes)"
#159: +1606971332 [appliance] "[ 0.000000] Memory: 485620K/511480K available (7827K kernel code, 1307K rwdata, 3444K rodata, 1528K init, 1544K bss, 25860K reserved, 0K cma-reserved)"
#160: +1608107744 [appliance] "[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1"
#161: +1608108658 [appliance] "[ 0.000000] Hierarchical RCU implementation."
#162: +1609246246 [appliance] "[ 0.000000] \x09Build-time adjustment of leaf fanout to 64."
#163: +1609247167 [appliance] "[ 0.000000] \x09RCU restricting CPUs from NR_CPUS=1024 to nr_cpu_ids=1."
#164: +1609247587 [appliance] "[ 0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=64, nr_cpu_ids=1"
#165: +1610381809 [appliance] "[ 0.000000] NR_IRQS:65792 nr_irqs:256 16"
#166: +1610382639 [appliance] "[ 0.000000] \x09Offload RCU callbacks from all CPUs"
#167: +1610383021 [appliance] "[ 0.000000] \x09Offload RCU callbacks from CPUs: 0."
#168: +1610383329 [appliance] "[ 0.000000] Console: colour *CGA 80x25"
#169: +1611513704 [appliance] "[ 0.000000] console [ttyS0] enabled"
#170: +1611523387 [appliance] "[ 0.000000] tsc: Detected 2593.994 MHz processor"
#171: +1611525750 [appliance] "[ 0.042262] Calibrating delay loop (skipped) preset value.. 5187.98 BogoMIPS (lpj=2593994)"
#172: +1612652134 [appliance] "[ 0.042843] pid_max: default: 32768 minimum: 301"
#173: +1612653040 [appliance] "[ 0.043193] Security Framework initialized"
#174: +1612653487 [appliance] "[ 0.043472] Yama: becoming mindful."
#175: +1612653880 [appliance] "[ 0.043711] SELinux: Disabled at boot."
#176: +1613794459 [appliance] "[ 0.044068] Dentry cache hash table entries: 65536 (order: 7, 524288 bytes)"
#177: +1613795431 [appliance] "[ 0.044604] Inode-cache hash table entries: 32768 (order: 6, 262144 bytes)"
#178: +1614925368 [appliance] "[ 0.045121] Mount-cache hash table entries: 1024 (order: 1, 8192 bytes)"
#179: +1614926332 [appliance] "[ 0.045559] Mountpoint-cache hash table entries: 1024 (order: 1, 8192 bytes)"
#180: +1616045743 [appliance] "[ 0.046187] Initializing cgroup subsys io"
#181: +1616046722 [appliance] "[ 0.046460] Initializing cgroup subsys memory"
#182: +1616047234 [appliance] "[ 0.046887] Disabling memory control group subsystem"
#183: +1617175974 [appliance] "[ 0.047259] Initializing cgroup subsys devices"
#184: +1617176910 [appliance] "[ 0.047557] Initializing cgroup subsys freezer"
#185: +1617177322 [appliance] "[ 0.047855] Initializing cgroup subsys net_cls"
#186: +1617177718 [appliance] "[ 0.048174] Initializing cgroup subsys perf_event"
#187: +1618307939 [appliance] "[ 0.048515] Initializing cgroup subsys net_prio"
#188: +1618308848 [appliance] "[ 0.048818] Initializing cgroup subsys hugetlb"
#189: +1618309245 [appliance] "[ 0.049139] Initializing cgroup subsys pids"
#190: +1620414486 [appliance] "[ 0.050387] mce: CPU supports 10 MCE banks"
#191: +1620415475 [appliance] "[ 0.050707] Last level iTLB entries: 4KB 0, 2MB 0, 4MB 0"
#192: +1620415939 [appliance] "[ 0.051085] Last level dTLB entries: 4KB 0, 2MB 0, 4MB 0, 1GB 0"
#193: +1630064973 [appliance] "[ 0.060050] Freeing SMP alternatives memory: 28K (ffffffff81ec6000 - ffffffff81ecd000)"
#194: +1632649831 [appliance] "[ 0.062646] ftrace: allocating 29522 entries in 116 pages"
#195: +1653444401 [appliance] "[ 0.083393] x2apic enabled"
#196: +1653445645 [appliance] "[ 0.083796] Switched APIC routing to physical x2apic."
#197: +1654838246 [appliance] "[ 0.084840] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1"
#198: +1654839305 [appliance] "[ 0.085289] smpboot: CPU0: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz (family: 0x6, model: 0x3d, stepping: 0x4)"
#199: +1655960262 [appliance] "[ 0.086006] Performance Events: 16-deep LBR, Broadwell events, Intel PMU driver."
#200: +1655960789 [appliance] "[ 0.086531] ... version: 2"
#201: +1655961291 [appliance] "[ 0.086794] ... bit width: 48"
#202: +1657108178 [appliance] "[ 0.087084] ... generic registers: 4"
#203: +1657109474 [appliance] "[ 0.087359] ... value mask: 0000ffffffffffff"
#204: +1657110234 [appliance] "[ 0.087701] ... max period: 000000007fffffff"
#205: +1657110836 [appliance] "[ 0.088063] ... fixed-purpose events: 3"
#206: +1658223691 [appliance] "[ 0.088330] ... event mask: 000000070000000f"
#207: +1658225233 [appliance] "[ 0.089151] x86: Booted up 1 node, 1 CPUs"
#208: +1659340853 [appliance] "[ 0.089448] smpboot: Total of 1 processors activated (5187.98 BogoMIPS)"
#209: +1659341827 [appliance] "[ 0.090115] devtmpfs: initialized"
#210: +1661568260 [appliance] "[ 0.091530] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1911260446275000 ns"
#211: +1661569302 [appliance] "[ 0.092268] atomic64_test: passed for x86-64 platform with CX8 and with SSE"
#212: +1662694646 [appliance] "[ 0.092750] pinctrl core: initialized pinctrl subsystem"
#213: +1662695546 [appliance] "[ 0.093153] RTC time: 20:24:26, date: 03/19/16"
#214: +1662695977 [appliance] "[ 0.093539] NET: Registered protocol family 16"
#215: +1663806449 [appliance] "[ 0.093980] cpuidle: using governor menu"
#216: +1663807345 [appliance] "[ 0.094401] PCI: Using configuration type 1 for base access"
#217: +1665652219 [appliance] "[ 0.095616] ACPI: Interpreter disabled."
#218: +1665653139 [appliance] "[ 0.095946] vgaarb: loaded"
#219: +1665653560 [appliance] "[ 0.096187] SCSI subsystem initialized"
#220: +1665653949 [appliance] "[ 0.096475] usbcore: registered new interface driver usbfs"
#221: +1666792431 [appliance] "[ 0.096863] usbcore: registered new interface driver hub"
#222: +1666793353 [appliance] "[ 0.097225] usbcore: registered new device driver usb"
#223: +1666793735 [appliance] "[ 0.097607] PCI: Probing PCI hardware"
#224: +1666794102 [appliance] "[ 0.097887] PCI host bridge to bus 0000:00"
#225: +1667925873 [appliance] "[ 0.098167] pci_bus 0000:00: root bus resource [io 0x0000-0xffff]"
#226: +1667926863 [appliance] "[ 0.098571] pci_bus 0000:00: root bus resource [mem 0x00000000-0xffffffffff]"
#227: +1667927268 [appliance] "[ 0.099039] pci_bus 0000:00: No busn resource found for root bus, will use [bus 00-ff]"
#228: +1673343067 [appliance] "[ 0.103280] pci 0000:00:01.1: legacy IDE quirk: reg 0x10: [io 0x01f0-0x01f7]"
#229: +1673345585 [appliance] "[ 0.103777] pci 0000:00:01.1: legacy IDE quirk: reg 0x14: [io 0x03f6]"
#230: +1673346357 [appliance] "[ 0.104230] pci 0000:00:01.1: legacy IDE quirk: reg 0x18: [io 0x0170-0x0177]"
#231: +1674466811 [appliance] "[ 0.104709] pci 0000:00:01.1: legacy IDE quirk: reg 0x1c: [io 0x0376]"
#232: +1674467844 [appliance] "[ 0.105490] pci 0000:00:01.3: quirk: [io 0x0600-0x063f] claimed by PIIX4 ACPI"
#233: +1675584768 [appliance] "[ 0.105985] pci 0000:00:01.3: quirk: [io 0x0700-0x070f] claimed by PIIX4 SMB"
#234: +1689964535 [appliance] "[ 0.119922] pci 0000:00:01.0: PIIX/ICH IRQ router [8086:7000]"
#235: +1689967098 [appliance] "[ 0.120499] NetLabel: Initializing"
#236: +1689967761 [appliance] "[ 0.120728] NetLabel: domain hash size = 128"
#237: +1689968323 [appliance] "[ 0.121053] NetLabel: protocols = UNLABELED CIPSOv4"
#238: +1691088290 [appliance] "[ 0.121401] NetLabel: unlabeled traffic allowed by default"
#239: +1691089981 [appliance] "[ 0.121858] clocksource: Switched to clocksource kvm-clock"
#240: +1697995693 [appliance] "[ 0.127981] pnp: PnP ACPI: disabled"
#241: +1697997632 [appliance] "[ 0.128998] NET: Registered protocol family 2"
#242: +1699112458 [appliance] "[ 0.129415] TCP established hash table entries: 4096 (order: 3, 32768 bytes)"
#243: +1699113625 [appliance] "[ 0.129895] TCP bind hash table entries: 4096 (order: 4, 65536 bytes)"
#244: +1700236700 [appliance] "[ 0.130351] TCP: Hash tables configured (established 4096 bind 4096)"
#245: +1700237620 [appliance] "[ 0.130953] UDP hash table entries: 256 (order: 1, 8192 bytes)"
#246: +1701368207 [appliance] "[ 0.131366] UDP-Lite hash table entries: 256 (order: 1, 8192 bytes)"
#247: +1701369177 [appliance] "[ 0.131815] NET: Registered protocol family 1"
#248: +1701370076 [appliance] "[ 0.132122] pci 0000:00:00.0: Limiting direct PCI/PCI transfers"
#249: +1702483982 [appliance] "[ 0.132544] pci 0000:00:01.0: PIIX3: Enabling Passive Release"
#250: +1702484956 [appliance] "[ 0.132936] pci 0000:00:01.0: Activating ISA DMA hang workarounds"
#251: +1702485470 [appliance] "[ 0.133402] Unpacking initramfs..."
#252: +1703589522 [appliance] "[ 0.133881] Freeing initrd memory: 344K (ffff88001f38a000 - ffff88001f3e0000)"
#253: +1703590458 [appliance] "[ 0.134430] platform rtc_cmos: registered platform RTC device (no PNP device found)"
#254: +1704697303 [appliance] "[ 0.135184] futex hash table entries: 256 (order: 2, 16384 bytes)"
#255: +1704698333 [appliance] "[ 0.135602] audit: initializing netlink subsys (disabled)"
#256: +1705808749 [appliance] "[ 0.136001] audit: type=2000 audit(1458419066.282:1): initialized"
#257: +1705809552 [appliance] "[ 0.136568] Initialise system trusted keyring"
#258: +1706944466 [appliance] "[ 0.136937] HugeTLB registered 1 GB page size, pre-allocated 0 pages"
#259: +1706945546 [appliance] "[ 0.137379] HugeTLB registered 2 MB page size, pre-allocated 0 pages"
#260: +1708707540 [appliance] "[ 0.138708] zbud: loaded"
#261: +1708708476 [appliance] "[ 0.139070] VFS: Disk quotas dquot_6.6.0"
#262: +1708708988 [appliance] "[ 0.139358] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes)"
#263: +1710072737 [appliance] "[ 0.140101] Key type big_key registered"
#264: +1711920499 [appliance] "[ 0.141902] NET: Registered protocol family 38"
#265: +1711921601 [appliance] "[ 0.142223] Key type asymmetric registered"
#266: +1711922113 [appliance] "[ 0.142495] Asymmetric key parser 'x509' registered"
#267: +1711922572 [appliance] "[ 0.142854] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 250)"
#268: +1713037042 [appliance] "[ 0.143410] io scheduler noop registered"
#269: +1713037914 [appliance] "[ 0.143674] io scheduler deadline registered"
#270: +1713038392 [appliance] "[ 0.143995] io scheduler cfq registered (default)"
#271: +1714157166 [appliance] "[ 0.144399] pci_hotplug: PCI Hot Plug PCI Core version: 0.5"
#272: +1714158085 [appliance] "[ 0.144768] pciehp: PCI Express Hot Plug Controller Driver version: 0.4"
#273: +1715294317 [appliance] "[ 0.145318] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled"
#274: +1738178724 [appliance] "[ 0.168189] serial8250: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A"
#275: +1739478589 [appliance] "[ 0.169486] Non-volatile memory driver v1.3"
#276: +1739479707 [appliance] "[ 0.169799] Linux agpgart interface v0.103"
#277: +1740837183 [appliance] "[ 0.170827] scsi host0: ata_piix"
#278: +1740838312 [appliance] "[ 0.171121] scsi host1: ata_piix"
#279: +1740838817 [appliance] "[ 0.171365] ata1: PATA max MWDMA2 cmd 0x1f0 ctl 0x3f6 bmdma 0xc060 irq 14"
#280: +1740839458 [appliance] "[ 0.171818] ata2: PATA max MWDMA2 cmd 0x170 ctl 0x376 bmdma 0xc068 irq 15"
#281: +1741948975 [appliance] "[ 0.172507] libphy: Fixed MDIO Bus: probed"
#282: +1741949994 [appliance] "[ 0.172827] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver"
#283: +1743066395 [appliance] "[ 0.173299] ehci-pci: EHCI PCI platform driver"
#284: +1743067201 [appliance] "[ 0.173611] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver"
#285: +1743067716 [appliance] "[ 0.174032] ohci-pci: OHCI PCI platform driver"
#286: +1744190185 [appliance] "[ 0.174367] uhci_hcd: USB Universal Host Controller Interface driver"
#287: +1744191069 [appliance] "[ 0.174825] usbcore: registered new interface driver usbserial"
#288: +1744191514 [appliance] "[ 0.175232] usbcore: registered new interface driver usbserial_generic"
#289: +1745311011 [appliance] "[ 0.175702] usbserial: USB Serial support registered for generic"
#290: +1745311905 [appliance] "[ 0.176130] i8042: PNP: No PS/2 controller found. Probing ports directly."
#291: +1746416901 [appliance] "[ 0.177094] serio: i8042 KBD port at 0x60,0x64 irq 1"
#292: +1746417700 [appliance] "[ 0.177431] serio: i8042 AUX port at 0x60,0x64 irq 12"
#293: +1747521164 [appliance] "[ 0.178020] mousedev: PS/2 mouse device common for all mice"
#294: +1747522144 [appliance] "[ 0.178549] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input0"
#295: +1748624000 [appliance] "[ 0.179544] input: VirtualPS/2 VMware VMMouse as /devices/platform/i8042/serio1/input/input3"
#296: +1749740522 [appliance] "[ 0.180276] input: VirtualPS/2 VMware VMMouse as /devices/platform/i8042/serio1/input/input2"
#297: +1751057789 [appliance] "[ 0.181056] rtc_cmos rtc_cmos: rtc core: registered rtc_cmos as rtc0"
#298: +1751058783 [appliance] "[ 0.181537] rtc_cmos rtc_cmos: alarms up to one day, 114 bytes nvram"
#299: +1751059336 [appliance] "[ 0.182007] device-mapper: uevent: version 1.0.3"
#300: +1752170554 [appliance] "[ 0.182432] device-mapper: ioctl: 4.34.0-ioctl (2015-10-28) initialised: dm-devel@redhat.com"
#301: +1752171475 [appliance] "[ 0.183078] hidraw: raw HID events driver (C) Jiri Kosina"
#302: +1753291705 [appliance] "[ 0.183492] usbcore: registered new interface driver usbhid"
#303: +1753292462 [appliance] "[ 0.183878] usbhid: USB HID core driver"
#304: +1753293005 [appliance] "[ 0.184171] drop_monitor: Initializing network drop monitor service"
#305: +1754402243 [appliance] "[ 0.184665] ip_tables: (C) 2000-2006 Netfilter Core Team"
#306: +1754403029 [appliance] "[ 0.185067] Initializing XFRM netlink socket"
#307: +1754403502 [appliance] "[ 0.185452] NET: Registered protocol family 10"
#308: +1755513666 [appliance] "[ 0.185896] mip6: Mobile IPv6"
#309: +1755514550 [appliance] "[ 0.186107] NET: Registered protocol family 17"
#310: +1755515005 [appliance] "[ 0.186529] microcode: CPU0 sig=0x306d4, pf=0x1, revision=0x1"
#311: +1756638526 [appliance] "[ 0.186963] microcode: Microcode Update Driver: v2.01 <tigran@aivazian.fsnet.co.uk>, Peter Oruba"
#312: +1756639342 [appliance] "[ 0.187560] AVX2 version of gcm_enc/dec engaged."
#313: +1757732608 [appliance] "[ 0.187904] AES CTR mode by8 optimization enabled"
#314: +1774292059 [appliance] "[ 0.204288] registered taskstats version 1"
#315: +1774293554 [appliance] "[ 0.204603] Loading compiled-in X.509 certificates"
#316: +1775522607 [appliance] "[ 0.205522] Loaded X.509 cert 'Fedora kernel signing key: ff671496ff3f386a8ef2031bac2201b2edb4da2a'"
#317: +1775523720 [appliance] "[ 0.206146] zswap: loaded using pool lzo/zbud"
#318: +1775524249 [appliance] "[ 0.206560] Magic number: 8:904:447"
#319: +1776615754 [appliance] "[ 0.206901] rtc_cmos rtc_cmos: setting system clock to 2016-03-19 20:24:26 UTC (1458419066)"
#320: +1899834142 [appliance] "[ 0.329811] Freeing unused kernel memory: 1528K (ffffffff81d48000 - ffffffff81ec6000)"
#321: +1899835969 [appliance] "[ 0.330370] Write protecting the kernel read-only data: 12288k"
#322: +1899836653 [appliance] "[ 0.330865] Freeing unused kernel memory: 352K (ffff8800017a8000 - ffff880001800000)"
#323: +1902526760 [appliance] "[ 0.332524] Freeing unused kernel memory: 652K (ffff880001b5d000 - ffff880001c00000)"
#324: +1902527912 [appliance] "supermin: mounting /proc"
#325: +1902528424 [appliance] "supermin: ext2 mini initrd starting up: 5.1.15 dietlibc"
#326: +1903700620 [appliance] "supermin: cmdline: panic=1 console=ttyS0 udevtimeout=6000 udev.event-timeout=6000 no_timer_check acpi=off printk.time=1 cgroup_disable=memory root=/dev/sdb selinux=0 guestfs_verbose=1 TERM=xterm-256color guestfs_boot_analysis=1"
#327: +1903701422 [appliance] "supermin: uptime: 0.27 0.14"
#328: +1904800827 [appliance] "supermin: mounting /sys"
#329: +1904801564 [appliance] "supermin: internal insmod crc32-pclmul.ko"
#330: +1906130645 [appliance] "supermin: internal insmod crc32c-intel.ko"
#331: +1906131567 [appliance] "supermin: internal insmod crct10dif-pclmul.ko"
#332: +1907219029 [appliance] "supermin: internal insmod crc32.ko"
#333: +1908298803 [appliance] "supermin: internal insmod virtio.ko"
#334: +1909384589 [appliance] "supermin: internal insmod virtio_ring.ko"
#335: +1911134934 [appliance] "supermin: internal insmod virtio_blk.ko"
#336: +1911135677 [appliance] "supermin: internal insmod virtio-rng.ko"
#337: +1912222514 [appliance] "supermin: internal insmod virtio_console.ko"
#338: +1913287906 [appliance] "supermin: internal insmod virtio_net.ko"
#339: +1915581045 [appliance] "supermin: internal insmod virtio_scsi.ko"
#340: +1916666873 [appliance] "supermin: internal insmod virtio_balloon.ko"
#341: +1916667598 [appliance] "supermin: internal insmod virtio_input.ko"
#342: +1917772686 [appliance] "supermin: internal insmod virtio_mmio.ko"
#343: +1918850939 [appliance] "supermin: internal insmod virtio_pci.ko"
#344: +1920841207 [appliance] "[ 0.350827] virtio-pci 0000:00:02.0: PCI->APIC IRQ transform: INT A -> IRQ 10"
#345: +1920842110 [appliance] "[ 0.351341] virtio-pci 0000:00:02.0: virtio_pci: leaving for legacy driver"
#346: +1922318872 [appliance] "[ 0.352322] scsi host2: Virtio SCSI HBA"
#347: +1922319637 [appliance] "[ 0.352709] virtio-pci 0000:00:03.0: PCI->APIC IRQ transform: INT A -> IRQ 11"
#348: +1922320008 [appliance] "[ 0.353237] virtio-pci 0000:00:03.0: virtio_pci: leaving for legacy driver"
#349: +1926506345 [appliance] "[ 0.356482] scsi 2:0:0:0: Direct-Access QEMU QEMU HARDDISK 2.5+ PQ: 0 ANSI: 5"
#350: +1926508007 [appliance] "[ 0.357293] scsi 2:0:1:0: Direct-Access QEMU QEMU HARDDISK 2.5+ PQ: 0 ANSI: 5"
#351: +1941735286 [appliance] "[ 0.371697] sd 2:0:0:0: Attached scsi generic sg0 type 0"
#352: +1941737135 [appliance] "[ 0.372347] sd 2:0:1:0: Attached scsi generic sg1 type 0"
#353: +1941737445 [appliance] "[ 0.372797] sd 2:0:0:0: [sda] 8 512-byte logical blocks: (4.10 kB/4.00 KiB)"
#354: +1942832586 [appliance] "[ 0.373588] sd 2:0:1:0: [sdb] 8388608 512-byte logical blocks: (4.29 GB/4.00 GiB)"
#355: +1943931328 [appliance] "[ 0.374267] sd 2:0:1:0: [sdb] Write Protect is off"
#356: +1943931871 [appliance] "[ 0.374602] sd 2:0:0:0: [sda] Write Protect is off"
#357: +1943932055 [appliance] "[ 0.375015] sd 2:0:1:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA"
#358: +1945058902 [appliance] "[ 0.375652] sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA"
#359: +1946142611 [appliance] "[ 0.376759] Dev sda: unable to read RDB block 8"
#360: +1946143180 [appliance] "[ 0.377104] sda: unable to read partition table"
#361: +1947252857 [appliance] "[ 0.377427] sda: partition table beyond EOD, enabling native capacity"
#362: +1947253337 [appliance] "[ 0.378152] sd 2:0:1:0: [sdb] Attached SCSI disk"
#363: +1948369443 [appliance] "[ 0.378661] Dev sda: unable to read RDB block 8"
#364: +1948370141 [appliance] "[ 0.378986] sda: unable to read partition table"
#365: +1948370331 [appliance] "[ 0.379290] sda: partition table beyond EOD, truncated"
#366: +1949481499 [appliance] "[ 0.379922] sd 2:0:0:0: [sda] Attached SCSI disk"
#367: +1949482241 [appliance] "supermin: internal insmod crc-ccitt.ko"
#368: +1951190886 [appliance] "supermin: internal insmod crc-itu-t.ko"
#369: +1951192058 [appliance] "supermin: internal insmod crc8.ko"
#370: +1952951762 [appliance] "supermin: internal insmod libcrc32c.ko"
#371: +1952952616 [appliance] "supermin: picked /sys/block/sdb/dev as root device"
#372: +1954066614 [appliance] "supermin: creating /dev/root as block special 8:16"
#373: +1954067396 [appliance] "supermin: mounting new root on /root"
#374: +1954067589 [appliance] "[ 0.385094] EXT4-fs (sdb): mounting ext2 file system using the ext4 subsystem"
#375: +1957705934 [appliance] "[ 0.387689] EXT4-fs (sdb): mounted filesystem without journal. Opts: "
#376: +1957711226 [appliance] "supermin: chroot"
#377: +1964770744 [appliance] "Starting /init script ..."
#378: +2057477213 [appliance] "[ 0.487433] random: systemd-tmpfile urandom read with 82 bits of entropy available"
#379: +2058797589 [appliance] "[/usr/lib/tmpfiles.d/journal-nocow.conf:26] Failed to replace specifiers: /var/log/journal/%m"
#380: +2060086479 [appliance] "[/usr/lib/tmpfiles.d/systemd.conf:26] Failed to replace specifiers: /run/log/journal/%m"
#381: +2060087195 [appliance] "[/usr/lib/tmpfiles.d/systemd.conf:28] Failed to replace specifiers: /run/log/journal/%m"
#382: +2060087505 [appliance] "[/usr/lib/tmpfiles.d/systemd.conf:29] Failed to replace specifiers: /run/log/journal/%m"
#383: +2061211993 [appliance] "[/usr/lib/tmpfiles.d/systemd.conf:32] Failed to replace specifiers: /var/log/journal/%m"
#384: +2061212343 [appliance] "[/usr/lib/tmpfiles.d/systemd.conf:33] Failed to replace specifiers: /var/log/journal/%m/system.journal"
#385: +2062639298 [appliance] "[/usr/lib/tmpfiles.d/systemd.conf:37] Failed to replace specifiers: /var/log/journal/%m"
#386: +2062639869 [appliance] "[/usr/lib/tmpfiles.d/systemd.conf:38] Failed to replace specifiers: /var/log/journal/%m"
#387: +2062640037 [appliance] "[/usr/lib/tmpfiles.d/systemd.conf:39] Failed to replace specifiers: /var/log/journal/%m/system.journal"
#388: +2064805195 [appliance] "UDEVD=/usr/lib/systemd/systemd-udevd"
#389: +2067059008 [appliance] "starting version 229"
#390: +2137052680 [appliance] "[ 0.567034] piix4_smbus 0000:00:01.3: PCI->APIC IRQ transform: INT A -> IRQ 9"
#391: +2137054745 [appliance] "[ 0.567539] piix4_smbus 0000:00:01.3: SMBus Host Controller at 0x700, revision 0"
#392: +2164342152 [appliance] "[ 0.594332] intel_rapl: no valid rapl domains found in package 0"
#393: +2185435472 [appliance] "[ 0.615415] random: nonblocking pool is initialized"
#394: +2192538565 [appliance] "[ 0.622520] input: PC Speaker as /devices/platform/pcspkr/input/input4"
#395: +2197190077 [appliance] "+ grep -sq guestfs_network=1 /proc/cmdline"
#396: +2197191974 [appliance] "+ grep -sq guestfs_rescue=1 /proc/cmdline"
#397: +2198655423 [appliance] "+ grep -sq guestfs_noreboot=1 /proc/cmdline"
#398: +2198656623 [appliance] "+ grep -sq guestfs_boot_analysis=1 /proc/cmdline"
#399: +2200104858 [appliance] "+ guestfs_boot_analysis=1"
#400: +2200105994 [appliance] "++ grep -Eo 'guestfs_channel=[^[:space:]]+' /proc/cmdline"
#401: +2200106415 [appliance] "+ eval"
#402: +2201229477 [appliance] "+ grep -sq selinux=1 /proc/cmdline"
#403: +2201230815 [appliance] "+ shopt -s nullglob"
#404: +2201231171 [appliance] "+ for f in '/sys/block/sd*/device/timeout'"
#405: +2202373812 [appliance] "+ echo 300"
#406: +2202375057 [appliance] "+ for f in '/sys/block/sd*/device/timeout'"
#407: +2202376044 [appliance] "+ echo 300"
#408: +2202376324 [appliance] "+ for f in '/sys/block/{h,s,ub,v}d*/queue/scheduler'"
#409: +2202376557 [appliance] "+ echo noop"
#410: +2202376837 [appliance] "+ for f in '/sys/block/{h,s,ub,v}d*/queue/scheduler'"
#411: +2203484518 [appliance] "+ echo noop"
#412: +2203485424 [appliance] "+ shopt -u nullglob"
#413: +2203485700 [appliance] "+ ip addr add 127.0.0.1/8 brd + dev lo scope host"
#414: +2205455231 [appliance] "+ ip link set dev lo up"
#415: +2205456930 [appliance] "+ test '' = 1"
#416: +2205457258 [appliance] "+ mdadm -As --auto=yes --run"
#417: +2208984940 [appliance] "mdadm: No arrays found in config file or automatically"
#418: +2208987086 [appliance] "+ modprobe dm_mod"
#419: +2210276415 [appliance] "+ lvmetad"
#420: +2212639128 [appliance] "+ lvm vgchange -aay --sysinit"
#421: +2215852737 [appliance] " Configuration setting "global/notify_dbus" unknown."
#422: +2215854439 [appliance] " lvmetad is not active yet, using direct activation during sysinit"
#423: +2218414676 [appliance] "+ ldmtool create all"
#424: +2221658701 [appliance] "["
#425: +2221660373 [appliance] "]"
#426: +2221660624 [appliance] "+ test 1 = 1"
#427: +2221660871 [appliance] "+ test 1 '!=' 1"
#428: +2221661083 [appliance] "+ test '' = 1"
#429: +2221661302 [appliance] "+ cmd=guestfsd"
#430: +2222804645 [appliance] "+ test x '!=' x"
#431: +2222805648 [appliance] "+ test 1 = 1"
#432: +2222805929 [appliance] "+ cmd='guestfsd --verbose'"
#433: +2222806165 [appliance] "+ test '' = 1"
#434: +2222806353 [appliance] "+ echo guestfsd --verbose"
#435: +2222806589 [appliance] "guestfsd --verbose"
#436: +2222806830 [appliance] "+ guestfsd --verbose"
#437: +2229192787 [appliance] "trying to open virtio-serial channel '/dev/virtio-ports/org.libguestfs.channel.0'"
#438: +2229194610 [appliance] "udevadm --debug settle"
#439: +2231316033 [appliance] "calling: settle"
#440: +2231321317 [launch_done] "launch done callback"
#441: +2231323092 [library] "recv_from_daemon: received GUESTFS_LAUNCH_FLAG"
#442: +2231328308 [library] "[02231ms] appliance is up"
#443: +2231350150 [trace] "launch = 0"
#444: +2231351178 [trace] "close"
#445: +2231352166 [library] "closing guestfs handle 0x564c2a8cd7a0 (state 2)"
#446: +2231363554 [trace] "internal_autosync"
#447: +2233992986 [appliance] "guestfsd: main_loop: new request, len 0x28"
#448: +2233994297 [appliance] "umount-all: /proc/mounts: fsname=/dev/root dir=/ type=ext2 opts=rw,noatime,block_validity,barrier,user_xattr,acl freq=0 passno=0"
#449: +2233994744 [appliance] "umount-all: /proc/mounts: fsname=/proc dir=/proc type=proc opts=rw,relatime freq=0 passno=0"
#450: +2235135420 [appliance] "umount-all: /proc/mounts: fsname=/sys dir=/sys type=sysfs opts=rw,relatime freq=0 passno=0"
#451: +2235136263 [appliance] "umount-all: /proc/mounts: fsname=tmpfs dir=/run type=tmpfs opts=rw,nosuid,relatime,size=97708k,mode=755 freq=0 passno=0"
#452: +2236272664 [appliance] "umount-all: /proc/mounts: fsname=/dev dir=/dev type=devtmpfs opts=rw,relatime,size=242824k,nr_inodes=60706,mode=755 freq=0 passno=0"
#453: +2238617992 [appliance] "fsync /dev/sda"
#454: +2240396178 [trace] "internal_autosync = 0"
#455: +2240398977 [library] "sending SIGTERM to process 18887"
#456: +2245358223 [close] "close callback"
#457: +2245364966 [library] "command: run: rm"
#458: +2245365846 [library] "command: run: \ -rf /home/rjones/d/libguestfs/tmp/libguestfsINdKan"
#459: +2246591810 [library] "command: run: rm"
#460: +2246592735 [library] "command: run: \ -rf /run/user/1000/libguestfsABLpPt"
Analyzing the results ...
activity 0:
name = run
start - end = 0.0 - 2235430052.0
mean elapsed = 2235430053.0
variance = 96822215069584.0
s.d = 9839828.0
percent = 100.0
activity 1:
name = supermin:build
start - end = 62176.0 - 10266826.5
mean elapsed = 10204651.5
variance = 223397862.2
s.d = 14946.5
percent = 0.5
activity 2:
name = qemu:feature-detect
start - end = 10286691.5 - 303110457.5
mean elapsed = 292823767.0
variance = 17039302481161.0
s.d = 4127869.0
percent = 13.1
activity 3:
name = qemu
start - end = 304859851.0 - 2235430052.0
mean elapsed = 1930570202.0
variance = 32829164146276.0
s.d = 5729674.0
percent = 86.4
activity 4:
name = qemu:overhead
start - end = 304859851.0 - 466518360.0
mean elapsed = 161658510.0
variance = 3146763783744.0
s.d = 1773912.0
percent = 7.2
activity 5:
name = seabios:overhead
start - end = 466518361.0 - 1571382665.0
mean elapsed = 1104864305.0
variance = 1447529015689.0
s.d = 1203133.0
percent = 49.4
activity 6:
name = kernel
start - end = 1571382666.0 - 2235430052.0
mean elapsed = 664047387.0
variance = 7576966411641.0
s.d = 2752629.0
percent = 29.7
activity 7:
name = kernel:overhead
start - end = 1571382666.0 - 1894133670.5
mean elapsed = 322751005.5
variance = 1486476681732.2
s.d = 1219211.5
percent = 14.4
activity 8:
name = supermin:mini-initrd
start - end = 1894133671.5 - 1949411338.5
mean elapsed = 55277668.0
variance = 8999557956.0
s.d = 94866.0
percent = 2.5
activity 9:
name = supermin: internal insmod crc32-pclmul.ko
start - end = 1896422166.0 - 1897754102.0
mean elapsed = 1331937.0
variance = 8156736.0
s.d = 2856.0
percent = 0.1
activity 10:
name = supermin: internal insmod crc32c-intel.ko
start - end = 1897754103.0 - 1897754970.5
mean elapsed = 868.5
variance = 2862.2
s.d = 53.5
percent = 0.0
activity 11:
name = supermin: internal insmod crct10dif-pclmul.ko
start - end = 1897754971.5 - 1898848742.5
mean elapsed = 1093772.0
variance = 39816100.0
s.d = 6310.0
percent = 0.0
activity 12:
name = supermin: internal insmod crc32.ko
start - end = 1898848743.5 - 1899965540.0
mean elapsed = 1116797.5
variance = 1370739552.2
s.d = 37023.5
percent = 0.0
activity 13:
name = supermin: internal insmod virtio.ko
start - end = 1899965541.0 - 1901361646.5
mean elapsed = 1396106.5
variance = 96298812720.2
s.d = 310320.5
percent = 0.1
activity 14:
name = supermin: internal insmod virtio_ring.ko
start - end = 1901361647.5 - 1902237219.5
mean elapsed = 875573.0
variance = 765226051984.0
s.d = 874772.0
percent = 0.0
activity 15:
name = supermin: internal insmod virtio_blk.ko
start - end = 1902237220.5 - 1902811371.5
mean elapsed = 574152.0
variance = 328797881281.0
s.d = 573409.0
percent = 0.0
activity 16:
name = supermin: internal insmod virtio-rng.ko
start - end = 1902811372.5 - 1903938709.0
mean elapsed = 1127337.5
variance = 1640290500.2
s.d = 40500.5
percent = 0.1
activity 17:
name = supermin: internal insmod virtio_console.ko
start - end = 1903938710.0 - 1905448112.0
mean elapsed = 1509403.0
variance = 197145768121.0
s.d = 444011.0
percent = 0.1
activity 18:
name = supermin: internal insmod virtio_net.ko
start - end = 1905448113.0 - 1907220846.5
mean elapsed = 1772734.5
variance = 270820843620.2
s.d = 520404.5
percent = 0.1
activity 19:
name = supermin: internal insmod virtio_scsi.ko
start - end = 1907220847.5 - 1907764156.0
mean elapsed = 543309.5
variance = 294326322842.2
s.d = 542518.5
percent = 0.0
activity 20:
name = supermin: internal insmod virtio_balloon.ko
start - end = 1907764157.0 - 1908314439.0
mean elapsed = 550283.0
variance = 302013995364.0
s.d = 549558.0
percent = 0.0
activity 21:
name = supermin: internal insmod virtio_input.ko
start - end = 1908314440.0 - 1909413933.5
mean elapsed = 1099494.5
variance = 31287242.2
s.d = 5593.5
percent = 0.0
activity 22:
name = supermin: internal insmod virtio_mmio.ko
start - end = 1909413934.5 - 1910503300.5
mean elapsed = 1089367.0
variance = 123520996.0
s.d = 11114.0
percent = 0.0
activity 23:
name = supermin: internal insmod virtio_pci.ko
start - end = 1910503301.5 - 1941148355.0
mean elapsed = 30645054.5
variance = 189131256.2
s.d = 13752.5
percent = 1.4
activity 24:
name = supermin: internal insmod crc-ccitt.ko
start - end = 1941148356.0 - 1942838889.0
mean elapsed = 1690534.0
variance = 328008321.0
s.d = 18111.0
percent = 0.1
activity 25:
name = supermin: internal insmod crc-itu-t.ko
start - end = 1942838890.0 - 1942839995.0
mean elapsed = 1106.0
variance = 4356.0
s.d = 66.0
percent = 0.0
activity 26:
name = supermin: internal insmod crc8.ko
start - end = 1942839996.0 - 1944270176.0
mean elapsed = 1430181.0
variance = 108585407529.0
s.d = 329523.0
percent = 0.1
activity 27:
name = supermin: internal insmod libcrc32c.ko
start - end = 1944270177.0 - 1945103937.5
mean elapsed = 833761.5
variance = 693734903556.2
s.d = 832907.5
percent = 0.0
activity 28:
name = /init
start - end = 1949411339.5 - 2210135132.5
mean elapsed = 260723794.0
variance = 19104845486281.0
s.d = 4370909.0
percent = 11.7
activity 29:
name = bash:overhead
start - end = 1949411339.5 - 1956248884.0
mean elapsed = 6837545.5
variance = 49271790756.2
s.d = 221972.5
percent = 0.3
activity 30:
name = guestfsd
start - end = 2210135133.5 - 2226245496.5
mean elapsed = 16110364.0
variance = 88983486601.0
s.d = 298301.0
percent = 0.7
activity 31:
name = shutdown
start - end = 2218921148.5 - 2235430052.0
mean elapsed = 16508904.5
variance = 6259300957740.2
s.d = 2501859.5
percent = 0.7
libguestfs 1.33.15
Host:
Appliance:
qemu version 2.5
\x1b[2J\x0dSeaBIOS (version 1.8.2-20150714_191134-)
[ 0.000000] Linux version 4.4.4-301.fc23.x86_64 (mockbuild@bkernel02.phx2.fedoraproject.org) (gcc version 5.3.1 20151207 (Red Hat 5.3.1-2) (GCC) ) #1 SMP Fri Mar 4 17:42:42 UTC 2016
supermin: ext2 mini initrd starting up: 5.1.15 dietlibc
0.000000s: ▲ run mean:2.235430s ±9.8ms (100.0%)
0.000062s: │ ▲ supermin:build mean:0.010205s ±0.0ms (0.5%)
│ │
0.010267s: │ ▼
0.010287s: │ ▲ qemu:feature-detect mean:0.292824s ±4.1ms (13.1%)
│ │
0.303110s: │ ▼
│
0.304860s: │ ▲ ▲ qemu mean:1.930570s ±5.7ms (86.4%) qemu:overhead mean:0.161659s ±1.8ms (7.2%)
│ │ │
0.466518s: │ │ ▼
0.466518s: │ │ ▲ seabios:overhead mean:1.104864s ±1.2ms (49.4%)
│ │ │
1.571383s: │ │ ▼
1.571383s: │ │ ▲ ▲ kernel mean:0.664047s ±2.8ms (29.7%) kernel:overhead mean:0.322751s ±1.2ms (14.4%)
│ │ │ │
1.894134s: │ │ │ ▼
1.894134s: │ │ │ ▲ supermin:mini-initrd mean:0.055278s ±0.1ms (2.5%)
│ │ │ │
1.896422s: │ │ │ │ ▲ supermin: internal insmod crc32-pclmul.ko mean:0.001332s ±0.0ms (0.1%)
│ │ │ │ │
1.897754s: │ │ │ │ ▼
1.897754s: │ │ │ │ ▲ supermin: internal insmod crc32c-intel.ko mean:0.000001s ±0.0ms (0.0%)
1.897755s: │ │ │ │ ▼
1.897755s: │ │ │ │ ▲ supermin: internal insmod crct10dif-pclmul.ko mean:0.001094s ±0.0ms (0.0%)
│ │ │ │ │
1.898849s: │ │ │ │ ▼
1.898849s: │ │ │ │ ▲ supermin: internal insmod crc32.ko mean:0.001117s ±0.0ms (0.0%)
│ │ │ │ │
1.899966s: │ │ │ │ ▼
1.899966s: │ │ │ │ ▲ supermin: internal insmod virtio.ko mean:0.001396s ±0.3ms (0.1%)
│ │ │ │ │
1.901362s: │ │ │ │ ▼
1.901362s: │ │ │ │ ▲ supermin: internal insmod virtio_ring.ko mean:0.000876s ±0.9ms (0.0%)
1.902237s: │ │ │ │ ▼
1.902237s: │ │ │ │ ▲ supermin: internal insmod virtio_blk.ko mean:0.000574s ±0.6ms (0.0%)
1.902811s: │ │ │ │ ▼
1.902811s: │ │ │ │ ▲ supermin: internal insmod virtio-rng.ko mean:0.001127s ±0.0ms (0.1%)
│ │ │ │ │
1.903939s: │ │ │ │ ▼
1.903939s: │ │ │ │ ▲ supermin: internal insmod virtio_console.ko mean:0.001509s ±0.4ms (0.1%)
│ │ │ │ │
1.905448s: │ │ │ │ ▼
1.905448s: │ │ │ │ ▲ supermin: internal insmod virtio_net.ko mean:0.001773s ±0.5ms (0.1%)
│ │ │ │ │
1.907221s: │ │ │ │ ▼
1.907221s: │ │ │ │ ▲ supermin: internal insmod virtio_scsi.ko mean:0.000543s ±0.5ms (0.0%)
1.907764s: │ │ │ │ ▼
1.907764s: │ │ │ │ ▲ supermin: internal insmod virtio_balloon.ko mean:0.000550s ±0.5ms (0.0%)
1.908314s: │ │ │ │ ▼
1.908314s: │ │ │ │ ▲ supermin: internal insmod virtio_input.ko mean:0.001099s ±0.0ms (0.0%)
│ │ │ │ │
1.909414s: │ │ │ │ ▼
1.909414s: │ │ │ │ ▲ supermin: internal insmod virtio_mmio.ko mean:0.001089s ±0.0ms (0.0%)
│ │ │ │ │
1.910503s: │ │ │ │ ▼
1.910503s: │ │ │ │ ▲ supermin: internal insmod virtio_pci.ko mean:0.030645s ±0.0ms (1.4%)
│ │ │ │ │
1.941148s: │ │ │ │ ▼
1.941148s: │ │ │ │ ▲ supermin: internal insmod crc-ccitt.ko mean:0.001691s ±0.0ms (0.1%)
│ │ │ │ │
1.942839s: │ │ │ │ ▼
1.942839s: │ │ │ │ ▲ supermin: internal insmod crc-itu-t.ko mean:0.000001s ±0.0ms (0.0%)
1.942840s: │ │ │ │ ▼
1.942840s: │ │ │ │ ▲ supermin: internal insmod crc8.ko mean:0.001430s ±0.3ms (0.1%)
│ │ │ │ │
1.944270s: │ │ │ │ ▼
1.944270s: │ │ │ │ ▲ supermin: internal insmod libcrc32c.ko mean:0.000834s ±0.8ms (0.0%)
1.945104s: │ │ │ │ ▼
│ │ │ │
1.949411s: │ │ │ ▼
1.949411s: │ │ │ ▲ ▲ /init mean:0.260724s ±4.4ms (11.7%) bash:overhead mean:0.006838s ±0.2ms (0.3%)
│ │ │ │ │
1.956249s: │ │ │ │ ▼
│ │ │ │
2.210135s: │ │ │ ▼
2.210135s: │ │ │ ▲ guestfsd mean:0.016110s ±0.3ms (0.7%)
│ │ │ │
2.218921s: │ │ │ │ ▲ shutdown mean:0.016509s ±2.5ms (0.7%)
│ │ │ │ │
2.226245s: │ │ │ ▼ │
│ │ │ │
2.235430s: ▼ ▼ ▼ ▼
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] Why is SeaBIOS used with -kernel?
2016-03-19 20:31 [Qemu-devel] Why is SeaBIOS used with -kernel? Richard W.M. Jones
@ 2016-03-21 7:58 ` Gerd Hoffmann
2016-03-21 8:37 ` Richard W.M. Jones
2016-03-31 9:21 ` Stefan Hajnoczi
1 sibling, 1 reply; 55+ messages in thread
From: Gerd Hoffmann @ 2016-03-21 7:58 UTC (permalink / raw)
To: Richard W.M. Jones; +Cc: Marc Marí, qemu-devel
On Sa, 2016-03-19 at 20:31 +0000, Richard W.M. Jones wrote:
> I've been analyzing the libguestfs appliance[1] boot time. See
> attached file, especially the end of it.
>
> About 50% of the boot time is because of SeaBIOS.
And the bulk of that is loading the kernel from fw_cfg.
> I'm using the qemu -kernel option. I understand that the kernel needs
> some BIOS features, eg. video stuff, E820. But kvmtool comes with a
> really minimal BIOS that implements a tiny number of calls[2] and is
> far faster than SeaBIOS.
>
> Is there something I'm missing, or for Linux + -kernel could we use a
> much simpler BIOS?
marc (cc'ed) worked on porting the linuxboot option rom over to use the
new fwcfg dma interface, which should make things a order of magnitude
faster. That seems to be stalled though. Marc?
cheers,
Gerd
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] Why is SeaBIOS used with -kernel?
2016-03-21 7:58 ` Gerd Hoffmann
@ 2016-03-21 8:37 ` Richard W.M. Jones
2016-03-21 9:40 ` Gerd Hoffmann
0 siblings, 1 reply; 55+ messages in thread
From: Richard W.M. Jones @ 2016-03-21 8:37 UTC (permalink / raw)
To: Gerd Hoffmann; +Cc: Marc Marí, qemu-devel
On Mon, Mar 21, 2016 at 08:58:27AM +0100, Gerd Hoffmann wrote:
> On Sa, 2016-03-19 at 20:31 +0000, Richard W.M. Jones wrote:
> > I've been analyzing the libguestfs appliance[1] boot time. See
> > attached file, especially the end of it.
> >
> > About 50% of the boot time is because of SeaBIOS.
>
> And the bulk of that is loading the kernel from fw_cfg.
Yes after further investigation that is correct. It looks like
fw_cfg has grown a DMA interface, but it's not used on x86.
There is still a considerable amount of SeaBIOS overhead. In
particular, it scans the whole of the PCI bus looking for boot
devices, but that work is both slow and completely unnecessary if
we're using the linuxbios option ROM to boot.
> > I'm using the qemu -kernel option. I understand that the kernel needs
> > some BIOS features, eg. video stuff, E820. But kvmtool comes with a
> > really minimal BIOS that implements a tiny number of calls[2] and is
> > far faster than SeaBIOS.
> >
> > Is there something I'm missing, or for Linux + -kernel could we use a
> > much simpler BIOS?
>
> marc (cc'ed) worked on porting the linuxboot option rom over to use the
> new fwcfg dma interface, which should make things a order of magnitude
> faster. That seems to be stalled though. Marc?
To Marc: Are there patches you can point me to?
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] Why is SeaBIOS used with -kernel?
2016-03-21 8:37 ` Richard W.M. Jones
@ 2016-03-21 9:40 ` Gerd Hoffmann
0 siblings, 0 replies; 55+ messages in thread
From: Gerd Hoffmann @ 2016-03-21 9:40 UTC (permalink / raw)
To: Richard W.M. Jones; +Cc: Marc Marí, qemu-devel
Hi,
> > And the bulk of that is loading the kernel from fw_cfg.
>
> Yes after further investigation that is correct. It looks like
> fw_cfg has grown a DMA interface, but it's not used on x86.
>
> There is still a considerable amount of SeaBIOS overhead. In
> particular, it scans the whole of the PCI bus looking for boot
> devices, but that work is both slow and completely unnecessary if
> we're using the linuxbios option ROM to boot.
There have been some experiments to strip down seabios config to speed
up things.
At least on q35 we also might consider using mmconfig, which I think
will reduce the number of vmexits needed for pci config space access.
Oh, and there also is qboot from paolo, but I think this is more a
proof-of-concept thing to see where the limit is.
cheers,
Gerd
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] Why is SeaBIOS used with -kernel?
2016-03-19 20:31 [Qemu-devel] Why is SeaBIOS used with -kernel? Richard W.M. Jones
2016-03-21 7:58 ` Gerd Hoffmann
@ 2016-03-31 9:21 ` Stefan Hajnoczi
2016-03-31 16:22 ` Kevin O'Connor
1 sibling, 1 reply; 55+ messages in thread
From: Stefan Hajnoczi @ 2016-03-31 9:21 UTC (permalink / raw)
To: Richard W.M. Jones; +Cc: marc.mari.barcelo, kevin, qemu-devel
[-- Attachment #1: Type: text/plain, Size: 700 bytes --]
On Sat, Mar 19, 2016 at 08:31:24PM +0000, Richard W.M. Jones wrote:
> Is there something I'm missing, or for Linux + -kernel could we use a
> much simpler BIOS?
The data that Marc Mari collected when comparing qboot with an optimized
SeaBIOS/QEMU showed that there's no need for a separate "lightweight
firmware" codebase.
https://github.com/bonzini/qboot
It would create a maintenance burden and eventually we'd want many of
the SeaBIOS features anyway. It's better to optimize linuxboot.bin and
SeaBIOS instead.
Kevin O'Connor had some SeaBIOS optimizations that improved boot time by
skipping unnecessary probing and timer calibration IIRC. I have CCed
Marc and Kevin on this email.
Stefan
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] Why is SeaBIOS used with -kernel?
2016-03-31 9:21 ` Stefan Hajnoczi
@ 2016-03-31 16:22 ` Kevin O'Connor
[not found] ` <20160331221039.GA32728@redhat.com>
0 siblings, 1 reply; 55+ messages in thread
From: Kevin O'Connor @ 2016-03-31 16:22 UTC (permalink / raw)
To: Stefan Hajnoczi; +Cc: marc.mari.barcelo, Richard W.M. Jones, qemu-devel
On Thu, Mar 31, 2016 at 10:21:25AM +0100, Stefan Hajnoczi wrote:
> On Sat, Mar 19, 2016 at 08:31:24PM +0000, Richard W.M. Jones wrote:
> > Is there something I'm missing, or for Linux + -kernel could we use a
> > much simpler BIOS?
>
> The data that Marc Mari collected when comparing qboot with an optimized
> SeaBIOS/QEMU showed that there's no need for a separate "lightweight
> firmware" codebase.
>
> https://github.com/bonzini/qboot
>
> It would create a maintenance burden and eventually we'd want many of
> the SeaBIOS features anyway. It's better to optimize linuxboot.bin and
> SeaBIOS instead.
In the tests I've run, the time spent in SeaBIOS is dominated by
hardware delays. (Or for qemu, the time needed for seabios to
communicate with virtual hardware and the time required for qemu to
implement the requests.) As such, boot times can be most easily
improved by configuring the VM with less hardware, or configuring (via
SeaBIOS kconfig) less hardware drivers in SeaBIOS.
It's possible to do course grained profiling with SeaBIOS by timing
its debug messages - see:
http://www.seabios.org/Debugging#Timing_debug_messages
The debug messages themselves can consume time though (one can
eliminate debug messages using CONFIG_DEBUG_LEVEL=0). I use the
following to profile while also accounting for the debug message delay
(on my system, each debug character takes ~2.5us):
scripts/readserial.py -f ../qemu-test/qemudebugpipe -t 2.5
I find a standard SeaBIOS build on my machine with KVM takes ~50ms to
start the OS (not including OS load time). This breaks down roughly
to the following times:
6ms - enabling shadow ram (qemu makes 0xc0000-0x100000 read/writable)
4ms - PCI initialization
2ms - smm init
4ms - load acpi tables from qemu
16ms - init and enable vga console
5ms - load and run various option roms from qemu (eg, ipxe)
7ms - locking shadow ram (qemu makes 0xc0000-0x100000 readonly)
6ms - other
There are several SeaBIOS kconfig options that would remove many of
the above delays (with the obvious caveat that the given hardware
would no longer be initialized by seabios).
> Kevin O'Connor had some SeaBIOS optimizations that improved boot time by
> skipping unnecessary probing and timer calibration IIRC. I have CCed
> Marc and Kevin on this email.
There were a couple of optimizations in SeaBIOS (avoid TSC calibration
when not using the TSC, avoid a PS2 keyboard reset delay) found last
year, but they were committed and released in SeaBIOS v1.9.0. They
should already be in QEMU.
Cheers,
-Kevin
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] Why is SeaBIOS used with -kernel?
[not found] ` <20160331221039.GA32728@redhat.com>
@ 2016-03-31 22:17 ` Richard W.M. Jones
2016-03-31 22:44 ` Kevin O'Connor
0 siblings, 1 reply; 55+ messages in thread
From: Richard W.M. Jones @ 2016-03-31 22:17 UTC (permalink / raw)
To: Kevin O'Connor; +Cc: marc.mari.barcelo, Stefan Hajnoczi, qemu-devel
[This time without the massive attachment]
On Thu, Mar 31, 2016 at 12:22:23PM -0400, Kevin O'Connor wrote:
> On Thu, Mar 31, 2016 at 10:21:25AM +0100, Stefan Hajnoczi wrote:
> > On Sat, Mar 19, 2016 at 08:31:24PM +0000, Richard W.M. Jones wrote:
> > > Is there something I'm missing, or for Linux + -kernel could we use a
> > > much simpler BIOS?
> >
> > The data that Marc Mari collected when comparing qboot with an optimized
> > SeaBIOS/QEMU showed that there's no need for a separate "lightweight
> > firmware" codebase.
[http://www.seabios.org/pipermail/seabios/2015-July/009554.html]
The problem is that now we've solved the fw_cfg problem, SeaBIOS is
again a bottleneck (but one of several, and not the biggest).
> > https://github.com/bonzini/qboot
I'm actually comparing this to the extremely minimal BIOS used by
kvmtool (and hence by Intel Clear Containers). That "BIOS" (it's
hardly fair to call it that) contains only a the bare minimum calls
necessary to service the Linux startup code. In this scenario Linux
is memcpy'd into the guest memory and jumped to directly, so there is
no separate BIOS loading step at all. The BIOS is only needed because
Linux startup issues BIOS calls eg to get the e820 memory map and do
some VGA mode manipulation.
https://git.kernel.org/cgit/linux/kernel/git/will/kvmtool.git/tree/x86
BTW my target for the total time taken to go from the qemu command to
a guest shell prompt is 150 ms. Intel Clear Containers can do this
already, albeit using kvmtool and a heavily patched kernel with a
minimal config.
> > It would create a maintenance burden and eventually we'd want many of
> > the SeaBIOS features anyway. It's better to optimize linuxboot.bin and
> > SeaBIOS instead.
>
> In the tests I've run, the time spent in SeaBIOS is dominated by
> hardware delays. (Or for qemu, the time needed for seabios to
> communicate with virtual hardware and the time required for qemu to
> implement the requests.) As such, boot times can be most easily
> improved by configuring the VM with less hardware, or configuring (via
> SeaBIOS kconfig) less hardware drivers in SeaBIOS.
>
> It's possible to do course grained profiling with SeaBIOS by timing
> its debug messages - see:
> http://www.seabios.org/Debugging#Timing_debug_messages
This is roughly what I've been doing. I'm using my own test harness:
https://github.com/libguestfs/libguestfs/blob/master/tests/qemu/boot-analysis.c
https://github.com/libguestfs/libguestfs/blob/master/tests/qemu/boot-analysis-timeline.c
The output from this is here (note: download it and use `less -r' to
view it):
http://oirase.annexia.org/tmp/seabios.txt
Actual total boot time is about 1s now. The attached file
takes longer for a couple of reasons:
- SeaBIOS debugging is enabled
- kernel initcall debugging is enabled
I'd dearly love to get rid of the sgabios option ROM. It looks like
SeaBIOS nearly supports a full serial console now?
> The debug messages themselves can consume time though (one can
> eliminate debug messages using CONFIG_DEBUG_LEVEL=0). I use the
> following to profile while also accounting for the debug message delay
> (on my system, each debug character takes ~2.5us):
>
> scripts/readserial.py -f ../qemu-test/qemudebugpipe -t 2.5
>
> I find a standard SeaBIOS build on my machine with KVM takes ~50ms to
> start the OS (not including OS load time). This breaks down roughly
> to the following times:
>
> 6ms - enabling shadow ram (qemu makes 0xc0000-0x100000 read/writable)
> 4ms - PCI initialization
> 2ms - smm init
> 4ms - load acpi tables from qemu
> 16ms - init and enable vga console
> 5ms - load and run various option roms from qemu (eg, ipxe)
> 7ms - locking shadow ram (qemu makes 0xc0000-0x100000 readonly)
> 6ms - other
>
> There are several SeaBIOS kconfig options that would remove many of
> the above delays (with the obvious caveat that the given hardware
> would no longer be initialized by seabios).
>
> > Kevin O'Connor had some SeaBIOS optimizations that improved boot time by
> > skipping unnecessary probing and timer calibration IIRC. I have CCed
> > Marc and Kevin on this email.
>
> There were a couple of optimizations in SeaBIOS (avoid TSC calibration
> when not using the TSC, avoid a PS2 keyboard reset delay) found last
> year, but they were committed and released in SeaBIOS v1.9.0. They
> should already be in QEMU.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] Why is SeaBIOS used with -kernel?
2016-03-31 22:17 ` Richard W.M. Jones
@ 2016-03-31 22:44 ` Kevin O'Connor
2016-04-01 7:55 ` Richard W.M. Jones
2016-04-01 8:02 ` Richard W.M. Jones
0 siblings, 2 replies; 55+ messages in thread
From: Kevin O'Connor @ 2016-03-31 22:44 UTC (permalink / raw)
To: Richard W.M. Jones; +Cc: marc.mari.barcelo, Stefan Hajnoczi, qemu-devel
On Thu, Mar 31, 2016 at 11:17:30PM +0100, Richard W.M. Jones wrote:
> On Thu, Mar 31, 2016 at 12:22:23PM -0400, Kevin O'Connor wrote:
> > On Thu, Mar 31, 2016 at 10:21:25AM +0100, Stefan Hajnoczi wrote:
> > > On Sat, Mar 19, 2016 at 08:31:24PM +0000, Richard W.M. Jones wrote:
> > > > Is there something I'm missing, or for Linux + -kernel could we use a
> > > > much simpler BIOS?
> > >
> > > The data that Marc Mari collected when comparing qboot with an optimized
> > > SeaBIOS/QEMU showed that there's no need for a separate "lightweight
> > > firmware" codebase.
>
> [http://www.seabios.org/pipermail/seabios/2015-July/009554.html]
>
> The problem is that now we've solved the fw_cfg problem, SeaBIOS is
> again a bottleneck (but one of several, and not the biggest).
>
> > > https://github.com/bonzini/qboot
>
> I'm actually comparing this to the extremely minimal BIOS used by
> kvmtool (and hence by Intel Clear Containers). That "BIOS" (it's
> hardly fair to call it that) contains only a the bare minimum calls
> necessary to service the Linux startup code. In this scenario Linux
> is memcpy'd into the guest memory and jumped to directly, so there is
> no separate BIOS loading step at all. The BIOS is only needed because
> Linux startup issues BIOS calls eg to get the e820 memory map and do
> some VGA mode manipulation.
I think you'll find that if you compile out some features from
SeaBIOS, it will be of a similar speed to that "minimal BIOS". Try
this:
cd /path/to/seabios/
echo -e 'CONFIG_USB=n\nCONFIG_DRIVES=n\nCONFIG_KEYBOARD=n\nCONFIG_MOUSE=n\nCONFIG_WRITABLE_UPPERMEMORY=y\nCONFIG_TCGBIOS=n\nCONFIG_PIRTABLE=n\nCONFIG_MPTABLE=n\nCONFIG_SMBIOS=n\nCONFIG_ACPI=n\nCONFIG_DEBUG_LEVEL=0' > .config
make olddefconfig
make
What time do you get with the above stripped down seabios (the
generated bios is in out/bios.bin)?
[...]
> I'd dearly love to get rid of the sgabios option ROM. It looks like
> SeaBIOS nearly supports a full serial console now?
Last I checked, one could disable the option rom by adding "-device
VGA,romfile=" to the qemu command line.
-Kevin
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] Why is SeaBIOS used with -kernel?
2016-03-31 22:44 ` Kevin O'Connor
@ 2016-04-01 7:55 ` Richard W.M. Jones
2016-04-01 8:03 ` Paolo Bonzini
2016-04-01 8:02 ` Richard W.M. Jones
1 sibling, 1 reply; 55+ messages in thread
From: Richard W.M. Jones @ 2016-04-01 7:55 UTC (permalink / raw)
To: Kevin O'Connor; +Cc: marc.mari.barcelo, Stefan Hajnoczi, qemu-devel
On Thu, Mar 31, 2016 at 06:44:32PM -0400, Kevin O'Connor wrote:
> On Thu, Mar 31, 2016 at 11:17:30PM +0100, Richard W.M. Jones wrote:
> > I'd dearly love to get rid of the sgabios option ROM. It looks like
> > SeaBIOS nearly supports a full serial console now?
>
> Last I checked, one could disable the option rom by adding "-device
> VGA,romfile=" to the qemu command line.
Sure, I can easily remove sgabios. The problem is I still want my
serial console to show BIOS messages!
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] Why is SeaBIOS used with -kernel?
2016-03-31 22:44 ` Kevin O'Connor
2016-04-01 7:55 ` Richard W.M. Jones
@ 2016-04-01 8:02 ` Richard W.M. Jones
2016-04-01 8:11 ` Paolo Bonzini
1 sibling, 1 reply; 55+ messages in thread
From: Richard W.M. Jones @ 2016-04-01 8:02 UTC (permalink / raw)
To: Kevin O'Connor; +Cc: marc.mari.barcelo, Stefan Hajnoczi, qemu-devel
[-- Attachment #1: Type: text/plain, Size: 1069 bytes --]
On Thu, Mar 31, 2016 at 06:44:32PM -0400, Kevin O'Connor wrote:
> I think you'll find that if you compile out some features from
> SeaBIOS, it will be of a similar speed to that "minimal BIOS". Try
> this:
>
> cd /path/to/seabios/
> echo -e 'CONFIG_USB=n\nCONFIG_DRIVES=n\nCONFIG_KEYBOARD=n\nCONFIG_MOUSE=n\nCONFIG_WRITABLE_UPPERMEMORY=y\nCONFIG_TCGBIOS=n\nCONFIG_PIRTABLE=n\nCONFIG_MPTABLE=n\nCONFIG_SMBIOS=n\nCONFIG_ACPI=n\nCONFIG_DEBUG_LEVEL=0' > .config
> make olddefconfig
> make
>
> What time do you get with the above stripped down seabios (the
> generated bios is in out/bios.bin)?
It's a bit unexpected: The kernel (not SeaBIOS) crashes or hangs
during virtio-scsi sensing. See attached. Any idea what I need to
enable?
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
[-- Attachment #2: crash.txt --]
[-- Type: text/plain, Size: 21793 bytes --]
./run test-tool/libguestfs-test-tool
************************************************************
* IMPORTANT NOTICE
*
* When reporting bugs, include the COMPLETE, UNEDITED
* output below in your bug report.
*
************************************************************
LIBGUESTFS_PATH=/home/rjones/d/libguestfs/appliance
LIBGUESTFS_CACHEDIR=/home/rjones/d/libguestfs/tmp
LD_LIBRARY_PATH=/home/rjones/d/libguestfs/ruby/ext/guestfs:/home/rjones/d/libguestfs/src/.libs:/home/rjones/d/libguestfs/java/.libs:/home/rjones/d/libguestfs/gobject/.libs
LIBGUESTFS_TMPDIR=/home/rjones/d/libguestfs/tmp
LIBGUESTFS_HV=/home/rjones/d/qemu/x86_64-softmmu/qemu-system-x86_64
LIBGUESTFS_BACKEND=direct
PATH=/home/rjones/d/libguestfs/v2v:/home/rjones/d/libguestfs/tools:/home/rjones/d/libguestfs/test-tool:/home/rjones/d/libguestfs/sysprep:/home/rjones/d/libguestfs/sparsify:/home/rjones/d/libguestfs/resize:/home/rjones/d/libguestfs/rescue:/home/rjones/d/libguestfs/p2v:/home/rjones/d/libguestfs/make-fs:/home/rjones/d/libguestfs/inspector:/home/rjones/d/libguestfs/get-kernel:/home/rjones/d/libguestfs/fuse:/home/rjones/d/libguestfs/format:/home/rjones/d/libguestfs/fish:/home/rjones/d/libguestfs/erlang:/home/rjones/d/libguestfs/edit:/home/rjones/d/libguestfs/diff:/home/rjones/d/libguestfs/dib:/home/rjones/d/libguestfs/df:/home/rjones/d/libguestfs/customize:/home/rjones/d/libguestfs/cat:/home/rjones/d/libguestfs/builder:/home/rjones/d/libguestfs/align:/usr/lib64/ccache:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/home/rjones/.local/bin:/home/rjones/bin
XDG_RUNTIME_DIR=/run/user/1000
SELinux: Enforcing
guestfs_get_append: (null)
guestfs_get_autosync: 1
guestfs_get_backend: direct
guestfs_get_backend_settings: []
guestfs_get_cachedir: /home/rjones/d/libguestfs/tmp
guestfs_get_direct: 0
guestfs_get_hv: /home/rjones/d/qemu/x86_64-softmmu/qemu-system-x86_64
guestfs_get_memsize: 500
guestfs_get_network: 0
guestfs_get_path: /home/rjones/d/libguestfs/appliance
guestfs_get_pgroup: 0
guestfs_get_program: libguestfs-test-tool
guestfs_get_recovery_proc: 1
guestfs_get_selinux: 0
guestfs_get_smp: 1
guestfs_get_sockdir: /run/user/1000
guestfs_get_tmpdir: /home/rjones/d/libguestfs/tmp
guestfs_get_trace: 0
guestfs_get_verbose: 1
host_cpu: x86_64
Launching appliance, timeout set to 600 seconds.
libguestfs: launch: program=libguestfs-test-tool
libguestfs: launch: version=1.33.16
libguestfs: launch: backend registered: unix
libguestfs: launch: backend registered: uml
libguestfs: launch: backend registered: libvirt
libguestfs: launch: backend registered: direct
libguestfs: launch: backend=direct
libguestfs: launch: tmpdir=/home/rjones/d/libguestfs/tmp/libguestfsT8B1IH
libguestfs: launch: umask=0002
libguestfs: launch: euid=1000
libguestfs: begin building supermin appliance
libguestfs: run supermin
libguestfs: command: run: /usr/bin/supermin
libguestfs: command: run: \ --build
libguestfs: command: run: \ --verbose
libguestfs: command: run: \ --if-newer
libguestfs: command: run: \ --lock /home/rjones/d/libguestfs/tmp/.guestfs-1000/lock
libguestfs: command: run: \ --copy-kernel
libguestfs: command: run: \ -f ext2
libguestfs: command: run: \ --host-cpu x86_64
libguestfs: command: run: \ /home/rjones/d/libguestfs/appliance/supermin.d
libguestfs: command: run: \ -o /home/rjones/d/libguestfs/tmp/.guestfs-1000/appliance.d
supermin: version: 5.1.15
supermin: rpm: detected RPM version 4.13
supermin: package handler: fedora/rpm
supermin: acquiring lock on /home/rjones/d/libguestfs/tmp/.guestfs-1000/lock
supermin: if-newer: output does not need rebuilding
libguestfs: finished building supermin appliance
libguestfs: begin testing qemu features
libguestfs: command: run: /home/rjones/d/qemu/x86_64-softmmu/qemu-system-x86_64
libguestfs: command: run: \ -display none
libguestfs: command: run: \ -help
libguestfs: qemu version 2.5
libguestfs: command: run: /home/rjones/d/qemu/x86_64-softmmu/qemu-system-x86_64
libguestfs: command: run: \ -display none
libguestfs: command: run: \ -machine accel=kvm:tcg
libguestfs: command: run: \ -device ?
libguestfs: finished testing qemu features
[00112ms] /home/rjones/d/qemu/x86_64-softmmu/qemu-system-x86_64 \
-global virtio-blk-pci.scsi=off \
-nodefconfig \
-enable-fips \
-nodefaults \
-display none \
-machine accel=kvm:tcg \
-cpu host \
-m 500 \
-no-reboot \
-rtc driftfix=slew \
-no-hpet \
-global kvm-pit.lost_tick_policy=discard \
-kernel /home/rjones/d/libguestfs/tmp/.guestfs-1000/appliance.d/kernel \
-initrd /home/rjones/d/libguestfs/tmp/.guestfs-1000/appliance.d/initrd \
-object rng-random,filename=/dev/urandom,id=rng0 \
-device virtio-rng-pci,rng=rng0 \
-device virtio-scsi-pci,id=scsi \
-drive file=/home/rjones/d/libguestfs/tmp/libguestfsT8B1IH/scratch.1,cache=unsafe,format=raw,id=hd0,if=none \
-device scsi-hd,drive=hd0 \
-drive file=/home/rjones/d/libguestfs/tmp/.guestfs-1000/appliance.d/root,snapshot=on,id=appliance,cache=unsafe,if=none \
-device scsi-hd,drive=appliance \
-device virtio-serial-pci \
-serial stdio \
-device sga \
-chardev socket,path=/run/user/1000/libguestfs9v9P6D/guestfsd.sock,id=channel0 \
-device virtserialport,chardev=channel0,name=org.libguestfs.channel.0 \
-append 'panic=1 console=ttyS0 udevtimeout=6000 udev.event-timeout=6000 no_timer_check acpi=off printk.time=1 cgroup_disable=memory root=/dev/sdb selinux=0 guestfs_verbose=1 TERM=xterm-256color'
libguestfs: responding to serial console Device Status Report
\x1b[1;256r\x1b[256;256H\x1b[6n
Google, Inc.
Serial Graphics Adapter 11/03/11
SGABIOS $Id$ (pbonzini@yakj.usersys.redhat.com) Thu Nov 3 13:33:51 UTC 2011
Term: 80x24
4 0
\x1b[2J
SeaBIOS (version rel-1.9.0-120-g6b76e69)
Booting from ROM...
Probing EDD (edd=off to disable)... ok
\x1b[2J[ 0.000000] Initializing cgroup subsys cpuset
[ 0.000000] Initializing cgroup subsys cpu
[ 0.000000] Initializing cgroup subsys cpuacct
[ 0.000000] Linux version 4.4.4-301.fc23.x86_64 (mockbuild@bkernel02.phx2.fedoraproject.org) (gcc version 5.3.1 20151207 (Red Hat 5.3.1-2) (GCC) ) #1 SMP Fri Mar 4 17:42:42 UTC 2016
[ 0.000000] Command line: panic=1 console=ttyS0 udevtimeout=6000 udev.event-timeout=6000 no_timer_check acpi=off printk.time=1 cgroup_disable=memory root=/dev/sdb selinux=0 guestfs_verbose=1 TERM=xterm-256color
[ 0.000000] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256
[ 0.000000] x86/fpu: Supporting XSAVE feature 0x01: 'x87 floating point registers'
[ 0.000000] x86/fpu: Supporting XSAVE feature 0x02: 'SSE registers'
[ 0.000000] x86/fpu: Supporting XSAVE feature 0x04: 'AVX registers'
[ 0.000000] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format.
[ 0.000000] x86/fpu: Using 'eager' FPU context switches.
[ 0.000000] e820: BIOS-provided physical RAM map:
[ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009f7ff] usable
[ 0.000000] BIOS-e820: [mem 0x000000000009f800-0x000000000009ffff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved
[ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000001f3dffff] usable
[ 0.000000] BIOS-e820: [mem 0x000000001f3e0000-0x000000001f3fffff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000feffc000-0x00000000feffffff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000fffc0000-0x00000000ffffffff] reserved
[ 0.000000] NX (Execute Disable) protection: active
[ 0.000000] SMBIOS 2.8 present.
[ 0.000000] Hypervisor detected: KVM
[ 0.000000] e820: last_pfn = 0x1f3e0 max_arch_pfn = 0x400000000
[ 0.000000] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WC UC- WT
[ 0.000000] Using GB pages for direct mapping
[ 0.000000] RAMDISK: [mem 0x00faa000-0x00ffffff]
[ 0.000000] No NUMA configuration found
[ 0.000000] Faking a node at [mem 0x0000000000000000-0x000000001f3dffff]
[ 0.000000] NODE_DATA(0) allocated [mem 0x1f3ce000-0x1f3dffff]
[ 0.000000] kvm-clock: Using msrs 4b564d01 and 4b564d00
[ 0.000000] kvm-clock: cpu 0, msr 0:1f3be001, primary cpu clock
[ 0.000000] kvm-clock: using sched offset of 108638070 cycles
[ 0.000000] clocksource: kvm-clock: mask: 0xffffffffffffffff max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns
[ 0.000000] Zone ranges:
[ 0.000000] DMA [mem 0x0000000000001000-0x0000000000ffffff]
[ 0.000000] DMA32 [mem 0x0000000001000000-0x000000001f3dffff]
[ 0.000000] Normal empty
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000000001000-0x000000000009efff]
[ 0.000000] node 0: [mem 0x0000000000100000-0x000000001f3dffff]
[ 0.000000] Initmem setup node 0 [mem 0x0000000000001000-0x000000001f3dffff]
[ 0.000000] SFI: Simple Firmware Interface v0.81 http://simplefirmware.org
[ 0.000000] smpboot: Allowing 1 CPUs, 0 hotplug CPUs
[ 0.000000] PM: Registered nosave memory: [mem 0x00000000-0x00000fff]
[ 0.000000] PM: Registered nosave memory: [mem 0x0009f000-0x0009ffff]
[ 0.000000] PM: Registered nosave memory: [mem 0x000a0000-0x000effff]
[ 0.000000] PM: Registered nosave memory: [mem 0x000f0000-0x000fffff]
[ 0.000000] e820: [mem 0x1f400000-0xfeffbfff] available for PCI devices
[ 0.000000] Booting paravirtualized kernel on KVM
[ 0.000000] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1910969940391419 ns
[ 0.000000] setup_percpu: NR_CPUS:1024 nr_cpumask_bits:1 nr_cpu_ids:1 nr_node_ids:1
[ 0.000000] PERCPU: Embedded 34 pages/cpu @ffff88001f000000 s98712 r8192 d32360 u2097152
[ 0.000000] KVM setup async PF for cpu 0
[ 0.000000] kvm-stealtime: cpu 0, msr 1f00d900
[ 0.000000] Built 1 zonelists in Node order, mobility grouping on. Total pages: 125763
[ 0.000000] Policy zone: DMA32
[ 0.000000] Kernel command line: panic=1 console=ttyS0 udevtimeout=6000 udev.event-timeout=6000 no_timer_check acpi=off printk.time=1 cgroup_disable=memory root=/dev/sdb selinux=0 guestfs_verbose=1 TERM=xterm-256color
[ 0.000000] PID hash table entries: 2048 (order: 2, 16384 bytes)
[ 0.000000] Memory: 485620K/511480K available (7827K kernel code, 1307K rwdata, 3444K rodata, 1528K init, 1544K bss, 25860K reserved, 0K cma-reserved)
[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[ 0.000000] Hierarchical RCU implementation.
[ 0.000000] \tBuild-time adjustment of leaf fanout to 64.
[ 0.000000] \tRCU restricting CPUs from NR_CPUS=1024 to nr_cpu_ids=1.
[ 0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=64, nr_cpu_ids=1
[ 0.000000] NR_IRQS:65792 nr_irqs:32 16
[ 0.000000] \tOffload RCU callbacks from all CPUs
[ 0.000000] \tOffload RCU callbacks from CPUs: 0.
[ 0.000000] Console: colour *CGA 80x25
[ 0.000000] console [ttyS0] enabled
[ 0.000000] tsc: Detected 2593.994 MHz processor
[ 0.049220] Calibrating delay loop (skipped) preset value.. 5187.98 BogoMIPS (lpj=2593994)
[ 0.049791] pid_max: default: 32768 minimum: 301
[ 0.050203] Security Framework initialized
[ 0.050481] Yama: becoming mindful.
[ 0.050719] SELinux: Disabled at boot.
[ 0.051055] Dentry cache hash table entries: 65536 (order: 7, 524288 bytes)
[ 0.051614] Inode-cache hash table entries: 32768 (order: 6, 262144 bytes)
[ 0.052151] Mount-cache hash table entries: 1024 (order: 1, 8192 bytes)
[ 0.052619] Mountpoint-cache hash table entries: 1024 (order: 1, 8192 bytes)
[ 0.053243] Initializing cgroup subsys io
[ 0.053544] Initializing cgroup subsys memory
[ 0.054000] Disabling memory control group subsystem
[ 0.054358] Initializing cgroup subsys devices
[ 0.054679] Initializing cgroup subsys freezer
[ 0.055003] Initializing cgroup subsys net_cls
[ 0.055302] Initializing cgroup subsys perf_event
[ 0.055647] Initializing cgroup subsys net_prio
[ 0.055992] Initializing cgroup subsys hugetlb
[ 0.056292] Initializing cgroup subsys pids
[ 0.057554] mce: CPU supports 10 MCE banks
[ 0.057927] Last level iTLB entries: 4KB 0, 2MB 0, 4MB 0
[ 0.058284] Last level dTLB entries: 4KB 0, 2MB 0, 4MB 0, 1GB 0
[ 0.068713] Freeing SMP alternatives memory: 28K (ffffffff81ec6000 - ffffffff81ecd000)
[ 0.071455] ftrace: allocating 29522 entries in 116 pages
[ 0.095900] smpboot: weird, boot CPU (#0) not listed by the BIOS
[ 0.096599] smpboot: SMP motherboard not detected
[ 0.097155] smpboot: SMP disabled
[ 0.097518] x2apic enabled
[ 0.097848] Switched APIC routing to physical x2apic.
[ 0.098544] Performance Events: 16-deep LBR, Broadwell events, Intel PMU driver.
[ 0.099316] ... version: 2
[ 0.099613] ... bit width: 48
[ 0.099922] ... generic registers: 4
[ 0.100254] ... value mask: 0000ffffffffffff
[ 0.100673] ... max period: 000000007fffffff
[ 0.101032] ... fixed-purpose events: 3
[ 0.101328] ... event mask: 000000070000000f
[ 0.102171] x86: Booted up 1 node, 1 CPUs
[ 0.102471] smpboot: Total of 1 processors activated (5187.98 BogoMIPS)
[ 0.103054] devtmpfs: initialized
[ 0.104596] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1911260446275000 ns
[ 0.105342] atomic64_test: passed for x86-64 platform with CX8 and with SSE
[ 0.105832] pinctrl core: initialized pinctrl subsystem
[ 0.106278] RTC time: 8:01:11, date: 04/01/16
[ 0.106717] NET: Registered protocol family 16
[ 0.107164] cpuidle: using governor menu
[ 0.107593] PCI: Using configuration type 1 for base access
[ 0.109331] ACPI: Interpreter disabled.
[ 0.109863] vgaarb: loaded
[ 0.110216] SCSI subsystem initialized
[ 0.110603] usbcore: registered new interface driver usbfs
[ 0.110982] usbcore: registered new interface driver hub
[ 0.111370] usbcore: registered new device driver usb
[ 0.111798] PCI: Probing PCI hardware
[ 0.112072] PCI host bridge to bus 0000:00
[ 0.112373] pci_bus 0000:00: root bus resource [io 0x0000-0xffff]
[ 0.112801] pci_bus 0000:00: root bus resource [mem 0x00000000-0xffffffffff]
[ 0.113284] pci_bus 0000:00: No busn resource found for root bus, will use [bus 00-ff]
[ 0.122996] pci 0000:00:01.1: legacy IDE quirk: reg 0x10: [io 0x01f0-0x01f7]
[ 0.123538] pci 0000:00:01.1: legacy IDE quirk: reg 0x14: [io 0x03f6]
[ 0.123978] pci 0000:00:01.1: legacy IDE quirk: reg 0x18: [io 0x0170-0x0177]
[ 0.124489] pci 0000:00:01.1: legacy IDE quirk: reg 0x1c: [io 0x0376]
[ 0.126815] pci 0000:00:01.3: quirk: [io 0x0600-0x063f] claimed by PIIX4 ACPI
[ 0.127607] pci 0000:00:01.3: quirk: [io 0x0700-0x070f] claimed by PIIX4 SMB
[ 0.202880] NetLabel: Initializing
[ 0.203366] NetLabel: domain hash size = 128
[ 0.203740] NetLabel: protocols = UNLABELED CIPSOv4
[ 0.204111] NetLabel: unlabeled traffic allowed by default
[ 0.204582] clocksource: Switched to clocksource kvm-clock
[ 0.212472] pnp: PnP ACPI: disabled
[ 0.214136] NET: Registered protocol family 2
[ 0.214635] TCP established hash table entries: 4096 (order: 3, 32768 bytes)
[ 0.215212] TCP bind hash table entries: 4096 (order: 4, 65536 bytes)
[ 0.215948] TCP: Hash tables configured (established 4096 bind 4096)
[ 0.217213] UDP hash table entries: 256 (order: 1, 8192 bytes)
[ 0.217722] UDP-Lite hash table entries: 256 (order: 1, 8192 bytes)
[ 0.218251] NET: Registered protocol family 1
[ 0.218571] pci 0000:00:00.0: Limiting direct PCI/PCI transfers
[ 0.219058] pci 0000:00:01.0: PIIX3: Enabling Passive Release
[ 0.219467] pci 0000:00:01.0: Activating ISA DMA hang workarounds
[ 0.220021] Unpacking initramfs...
[ 0.220467] Freeing initrd memory: 344K (ffff880000faa000 - ffff880001000000)
[ 0.221041] platform rtc_cmos: registered platform RTC device (no PNP device found)
[ 0.221927] futex hash table entries: 256 (order: 2, 16384 bytes)
[ 0.222489] audit: initializing netlink subsys (disabled)
[ 0.222929] audit: type=2000 audit(1459497671.940:1): initialized
[ 0.223552] Initialise system trusted keyring
[ 0.223952] HugeTLB registered 1 GB page size, pre-allocated 0 pages
[ 0.224392] HugeTLB registered 2 MB page size, pre-allocated 0 pages
[ 0.225770] zbud: loaded
[ 0.226182] VFS: Disk quotas dquot_6.6.0
[ 0.226489] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[ 0.227282] Key type big_key registered
[ 0.229286] NET: Registered protocol family 38
[ 0.229653] Key type asymmetric registered
[ 0.229961] Asymmetric key parser 'x509' registered
[ 0.230394] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 250)
[ 0.231291] io scheduler noop registered
[ 0.231781] io scheduler deadline registered
[ 0.232344] io scheduler cfq registered (default)
[ 0.232900] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
[ 0.233330] pciehp: PCI Express Hot Plug Controller Driver version: 0.4
[ 0.233975] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled
[ 0.256483] serial8250: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
[ 0.257814] Non-volatile memory driver v1.3
[ 0.258154] Linux agpgart interface v0.103
[ 0.259133] scsi host0: ata_piix
[ 0.259422] scsi host1: ata_piix
[ 0.259690] ata1: PATA max MWDMA2 cmd 0x1f0 ctl 0x3f6 bmdma 0xc080 irq 14
[ 0.260165] ata2: PATA max MWDMA2 cmd 0x170 ctl 0x376 bmdma 0xc088 irq 15
[ 0.260859] libphy: Fixed MDIO Bus: probed
[ 0.261194] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[ 0.261661] ehci-pci: EHCI PCI platform driver
[ 0.261984] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[ 0.262418] ohci-pci: OHCI PCI platform driver
[ 0.262748] uhci_hcd: USB Universal Host Controller Interface driver
[ 0.263246] usbcore: registered new interface driver usbserial
[ 0.263670] usbcore: registered new interface driver usbserial_generic
[ 0.264139] usbserial: USB Serial support registered for generic
[ 0.264678] i8042: PNP: No PS/2 controller found. Probing ports directly.
[ 0.265846] serio: i8042 KBD port at 0x60,0x64 irq 1
[ 0.266203] serio: i8042 AUX port at 0x60,0x64 irq 12
[ 0.266824] mousedev: PS/2 mouse device common for all mice
[ 0.267411] input: AT Raw Set 2 keyboard as /devices/platform/i8042/serio0/input/input0
[ 0.268454] input: VirtualPS/2 VMware VMMouse as /devices/platform/i8042/serio1/input/input3
[ 0.269237] input: VirtualPS/2 VMware VMMouse as /devices/platform/i8042/serio1/input/input2
[ 0.270058] rtc_cmos rtc_cmos: rtc core: registered rtc_cmos as rtc0
[ 0.270540] rtc_cmos rtc_cmos: alarms up to one day, 114 bytes nvram
[ 0.271109] device-mapper: uevent: version 1.0.3
[ 0.271522] device-mapper: ioctl: 4.34.0-ioctl (2015-10-28) initialised: dm-devel@redhat.com
[ 0.272261] hidraw: raw HID events driver (C) Jiri Kosina
[ 0.272656] usbcore: registered new interface driver usbhid
[ 0.273100] usbhid: USB HID core driver
[ 0.273605] drop_monitor: Initializing network drop monitor service
[ 0.274148] ip_tables: (C) 2000-2006 Netfilter Core Team
[ 0.274592] Initializing XFRM netlink socket
[ 0.275006] NET: Registered protocol family 10
[ 0.275510] mip6: Mobile IPv6
[ 0.275741] NET: Registered protocol family 17
[ 0.276188] microcode: CPU0 sig=0x306d4, pf=0x1, revision=0x1
[ 0.276685] microcode: Microcode Update Driver: v2.01 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
[ 0.277318] AVX2 version of gcm_enc/dec engaged.
[ 0.277704] AES CTR mode by8 optimization enabled
[ 0.295438] registered taskstats version 1
[ 0.295912] Loading compiled-in X.509 certificates
[ 0.296907] Loaded X.509 cert 'Fedora kernel signing key: ff671496ff3f386a8ef2031bac2201b2edb4da2a'
[ 0.297610] zswap: loaded using pool lzo/zbud
[ 0.298249] Magic number: 12:867:16
[ 0.298630] rtc_cmos rtc_cmos: setting system clock to 2016-04-01 08:01:11 UTC (1459497671)
[ 0.418595] Freeing unused kernel memory: 1528K (ffffffff81d48000 - ffffffff81ec6000)
[ 0.419161] Write protecting the kernel read-only data: 12288k
[ 0.419696] Freeing unused kernel memory: 352K (ffff8800017a8000 - ffff880001800000)
[ 0.421419] Freeing unused kernel memory: 652K (ffff880001b5d000 - ffff880001c00000)
supermin: mounting /proc
supermin: ext2 mini initrd starting up: 5.1.15 dietlibc
supermin: cmdline: panic=1 console=ttyS0 udevtimeout=6000 udev.event-timeout=6000 no_timer_check acpi=off printk.time=1 cgroup_disable=memory root=/dev/sdb selinux=0 guestfs_verbose=1 TERM=xterm-256color
supermin: uptime: 0.30 0.14
supermin: mounting /sys
supermin: internal insmod crc32-pclmul.ko
supermin: internal insmod crc32c-intel.ko
supermin: internal insmod crct10dif-pclmul.ko
supermin: internal insmod crc32.ko
supermin: internal insmod virtio.ko
supermin: internal insmod virtio_ring.ko
supermin: internal insmod virtio_blk.ko
supermin: internal insmod virtio-rng.ko
supermin: internal insmod virtio_console.ko
supermin: internal insmod virtio_net.ko
supermin: internal insmod virtio_scsi.ko
supermin: internal insmod virtio_balloon.ko
supermin: internal insmod virtio_input.ko
supermin: internal insmod virtio_mmio.ko
supermin: internal insmod virtio_pci.ko
[ 0.441266] virtio-pci 0000:00:02.0: virtio_pci: leaving for legacy driver
[ 0.442677] virtio-pci 0000:00:03.0: virtio_pci: leaving for legacy driver
[ 0.444594] scsi host2: Virtio SCSI HBA
[ 0.445069] virtio-pci 0000:00:04.0: virtio_pci: leaving for legacy driver
[ 1.222696] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x256412811b4, max_idle_ns: 440795306987 ns
[ 21.854699] scsi 2:0:0:0: tag#0 abort
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] Why is SeaBIOS used with -kernel?
2016-04-01 7:55 ` Richard W.M. Jones
@ 2016-04-01 8:03 ` Paolo Bonzini
2016-04-01 8:47 ` Richard W.M. Jones
0 siblings, 1 reply; 55+ messages in thread
From: Paolo Bonzini @ 2016-04-01 8:03 UTC (permalink / raw)
To: Richard W.M. Jones, Kevin O'Connor
Cc: marc.mari.barcelo, Stefan Hajnoczi, qemu-devel
On 01/04/2016 09:55, Richard W.M. Jones wrote:
>>> > > I'd dearly love to get rid of the sgabios option ROM. It looks like
>>> > > SeaBIOS nearly supports a full serial console now?
>> >
>> > Last I checked, one could disable the option rom by adding "-device
>> > VGA,romfile=" to the qemu command line.
> Sure, I can easily remove sgabios. The problem is I still want my
> serial console to show BIOS messages!
What do you need it for?
Paolo
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] Why is SeaBIOS used with -kernel?
2016-04-01 8:02 ` Richard W.M. Jones
@ 2016-04-01 8:11 ` Paolo Bonzini
2016-04-01 8:14 ` Richard W.M. Jones
2016-04-01 8:19 ` Richard W.M. Jones
0 siblings, 2 replies; 55+ messages in thread
From: Paolo Bonzini @ 2016-04-01 8:11 UTC (permalink / raw)
To: Richard W.M. Jones, Kevin O'Connor
Cc: marc.mari.barcelo, Stefan Hajnoczi, qemu-devel
On 01/04/2016 10:02, Richard W.M. Jones wrote:
>> > echo -e 'CONFIG_USB=n\nCONFIG_DRIVES=n\nCONFIG_KEYBOARD=n\nCONFIG_MOUSE=n\nCONFIG_WRITABLE_UPPERMEMORY=y\nCONFIG_TCGBIOS=n\nCONFIG_PIRTABLE=n\nCONFIG_MPTABLE=n\nCONFIG_SMBIOS=n\nCONFIG_ACPI=n\nCONFIG_DEBUG_LEVEL=0' > .config
>> > make olddefconfig
>> > make
>> >
>> > What time do you get with the above stripped down seabios (the
>> > generated bios is in out/bios.bin)?
> It's a bit unexpected: The kernel (not SeaBIOS) crashes or hangs
> during virtio-scsi sensing. See attached. Any idea what I need to
> enable?
At least ACPI (I would also add mptable and SMBIOS).
Paolo
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] Why is SeaBIOS used with -kernel?
2016-04-01 8:11 ` Paolo Bonzini
@ 2016-04-01 8:14 ` Richard W.M. Jones
2016-04-01 8:24 ` Paolo Bonzini
2016-04-01 8:19 ` Richard W.M. Jones
1 sibling, 1 reply; 55+ messages in thread
From: Richard W.M. Jones @ 2016-04-01 8:14 UTC (permalink / raw)
To: Paolo Bonzini
Cc: marc.mari.barcelo, Stefan Hajnoczi, Kevin O'Connor, qemu-devel
On Fri, Apr 01, 2016 at 10:11:46AM +0200, Paolo Bonzini wrote:
>
>
> On 01/04/2016 10:02, Richard W.M. Jones wrote:
> >> > echo -e 'CONFIG_USB=n\nCONFIG_DRIVES=n\nCONFIG_KEYBOARD=n\nCONFIG_MOUSE=n\nCONFIG_WRITABLE_UPPERMEMORY=y\nCONFIG_TCGBIOS=n\nCONFIG_PIRTABLE=n\nCONFIG_MPTABLE=n\nCONFIG_SMBIOS=n\nCONFIG_ACPI=n\nCONFIG_DEBUG_LEVEL=0' > .config
> >> > make olddefconfig
> >> > make
> >> >
> >> > What time do you get with the above stripped down seabios (the
> >> > generated bios is in out/bios.bin)?
> > It's a bit unexpected: The kernel (not SeaBIOS) crashes or hangs
> > during virtio-scsi sensing. See attached. Any idea what I need to
> > enable?
>
> At least ACPI (I would also add mptable and SMBIOS).
Found it: only CONFIG_MPTABLE=y was necessary. It boots with:
# CONFIG_PIRTABLE is not set
CONFIG_MPTABLE=y
# CONFIG_SMBIOS is not set
# CONFIG_ACPI is not set
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] Why is SeaBIOS used with -kernel?
2016-04-01 8:11 ` Paolo Bonzini
2016-04-01 8:14 ` Richard W.M. Jones
@ 2016-04-01 8:19 ` Richard W.M. Jones
1 sibling, 0 replies; 55+ messages in thread
From: Richard W.M. Jones @ 2016-04-01 8:19 UTC (permalink / raw)
To: Paolo Bonzini
Cc: marc.mari.barcelo, Stefan Hajnoczi, Kevin O'Connor, qemu-devel
Minimal SeaBIOS (+ CONFIG_MPTABLE):
http://oirase.annexia.org/tmp/min-seabios.txt
Stock SeaBIOS from qemu:
http://oirase.annexia.org/tmp/stock-seabios.txt
Both files best viewed with `less -r'.
It does appear to considerably reduce SeaBIOS time.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] Why is SeaBIOS used with -kernel?
2016-04-01 8:14 ` Richard W.M. Jones
@ 2016-04-01 8:24 ` Paolo Bonzini
2016-04-01 8:44 ` Richard W.M. Jones
0 siblings, 1 reply; 55+ messages in thread
From: Paolo Bonzini @ 2016-04-01 8:24 UTC (permalink / raw)
To: Richard W.M. Jones
Cc: marc.mari.barcelo, Stefan Hajnoczi, Kevin O'Connor, qemu-devel
On 01/04/2016 10:14, Richard W.M. Jones wrote:
>> > At least ACPI (I would also add mptable and SMBIOS).
> Found it: only CONFIG_MPTABLE=y was necessary. It boots with:
>
> # CONFIG_PIRTABLE is not set
> CONFIG_MPTABLE=y
> # CONFIG_SMBIOS is not set
> # CONFIG_ACPI is not set
If you add all three it should not give any slowdown and will provide
full hardware features to the kernel. qboot does ACPI and PCI bus
assignment (it doesn't do SMBIOS because I got bored debugging it. :))
Paolo
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] Why is SeaBIOS used with -kernel?
2016-04-01 8:24 ` Paolo Bonzini
@ 2016-04-01 8:44 ` Richard W.M. Jones
2016-04-01 8:47 ` Paolo Bonzini
` (3 more replies)
0 siblings, 4 replies; 55+ messages in thread
From: Richard W.M. Jones @ 2016-04-01 8:44 UTC (permalink / raw)
To: Paolo Bonzini
Cc: marc.mari.barcelo, Stefan Hajnoczi, Kevin O'Connor, qemu-devel
On Fri, Apr 01, 2016 at 10:24:37AM +0200, Paolo Bonzini wrote:
> On 01/04/2016 10:14, Richard W.M. Jones wrote:
> > Found it: only CONFIG_MPTABLE=y was necessary. It boots with:
> >
> > # CONFIG_PIRTABLE is not set
> > CONFIG_MPTABLE=y
> > # CONFIG_SMBIOS is not set
> > # CONFIG_ACPI is not set
>
> If you add all three it should not give any slowdown and will provide
> full hardware features to the kernel. qboot does ACPI and PCI bus
> assignment (it doesn't do SMBIOS because I got bored debugging it. :))
Enabling all 4 adds about 2ms.
However the overhead of SeaBIOS is still down from 68ms to 18ms
(4.0% of total boot time down to 1.1%) so it's still a big gain.
I wonder how we can make use of this in qemu and downstream distros?
Can we have a bios-min.bin which is used with -kernel boots?
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://libguestfs.org
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] Why is SeaBIOS used with -kernel?
2016-04-01 8:44 ` Richard W.M. Jones
@ 2016-04-01 8:47 ` Paolo Bonzini
2016-04-01 8:49 ` Vasiliy Tolstov
2016-04-01 9:16 ` Dr. David Alan Gilbert
` (2 subsequent siblings)
3 siblings, 1 reply; 55+ messages in thread
From: Paolo Bonzini @ 2016-04-01 8:47 UTC (permalink / raw)
To: Richard W.M. Jones
Cc: marc.mari.barcelo, Stefan Hajnoczi, Kevin O'Connor, qemu-devel
On 01/04/2016 10:44, Richard W.M. Jones wrote:
> On Fri, Apr 01, 2016 at 10:24:37AM +0200, Paolo Bonzini wrote:
>> On 01/04/2016 10:14, Richard W.M. Jones wrote:
>>> Found it: only CONFIG_MPTABLE=y was necessary. It boots with:
>>>
>>> # CONFIG_PIRTABLE is not set
>>> CONFIG_MPTABLE=y
>>> # CONFIG_SMBIOS is not set
>>> # CONFIG_ACPI is not set
>>
>> If you add all three it should not give any slowdown and will provide
>> full hardware features to the kernel. qboot does ACPI and PCI bus
>> assignment (it doesn't do SMBIOS because I got bored debugging it. :))
>
> Enabling all 4 adds about 2ms.
>
> However the overhead of SeaBIOS is still down from 68ms to 18ms
> (4.0% of total boot time down to 1.1%) so it's still a big gain.
>
> I wonder how we can make use of this in qemu and downstream distros?
> Can we have a bios-min.bin which is used with -kernel boots?
That's an interesting idea. We can look at it for 2.7.
Paolo
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] Why is SeaBIOS used with -kernel?
2016-04-01 8:03 ` Paolo Bonzini
@ 2016-04-01 8:47 ` Richard W.M. Jones
2016-04-01 8:51 ` Paolo Bonzini
0 siblings, 1 reply; 55+ messages in thread
From: Richard W.M. Jones @ 2016-04-01 8:47 UTC (permalink / raw)
To: Paolo Bonzini
Cc: marc.mari.barcelo, Stefan Hajnoczi, Kevin O'Connor, qemu-devel
On Fri, Apr 01, 2016 at 10:03:10AM +0200, Paolo Bonzini wrote:
>
>
> On 01/04/2016 09:55, Richard W.M. Jones wrote:
> >>> > > I'd dearly love to get rid of the sgabios option ROM. It looks like
> >>> > > SeaBIOS nearly supports a full serial console now?
> >> >
> >> > Last I checked, one could disable the option rom by adding "-device
> >> > VGA,romfile=" to the qemu command line.
> > Sure, I can easily remove sgabios. The problem is I still want my
> > serial console to show BIOS messages!
>
> What do you need it for?
It's so we can handle error reports. When someone reports that
libguestfs "hangs", it's sometimes useful to know if the BIOS was
entered or not, since it points the finger at either qemu, BIOS or
kernel. (Remember we have to be able to run on a whole variety of
Linux distros which often have old/broken/random qemu/bios/kernel).
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] Why is SeaBIOS used with -kernel?
2016-04-01 8:47 ` Paolo Bonzini
@ 2016-04-01 8:49 ` Vasiliy Tolstov
0 siblings, 0 replies; 55+ messages in thread
From: Vasiliy Tolstov @ 2016-04-01 8:49 UTC (permalink / raw)
To: Paolo Bonzini
Cc: marc.mari.barcelo, Stefan Hajnoczi, Kevin O'Connor,
Richard W.M. Jones, qemu-devel
2016-04-01 11:47 GMT+03:00 Paolo Bonzini <pbonzini@redhat.com>:
> That's an interesting idea. We can look at it for 2.7.
That's fine =) I'm waiting too.
--
Vasiliy Tolstov,
e-mail: v.tolstov@selfip.ru
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] Why is SeaBIOS used with -kernel?
2016-04-01 8:47 ` Richard W.M. Jones
@ 2016-04-01 8:51 ` Paolo Bonzini
2016-04-01 8:57 ` Richard W.M. Jones
0 siblings, 1 reply; 55+ messages in thread
From: Paolo Bonzini @ 2016-04-01 8:51 UTC (permalink / raw)
To: Richard W.M. Jones
Cc: marc.mari.barcelo, Stefan Hajnoczi, Kevin O'Connor, qemu-devel
On 01/04/2016 10:47, Richard W.M. Jones wrote:
> It's so we can handle error reports. When someone reports that
> libguestfs "hangs", it's sometimes useful to know if the BIOS was
> entered or not, since it points the finger at either qemu, BIOS or
> kernel. (Remember we have to be able to run on a whole variety of
> Linux distros which often have old/broken/random qemu/bios/kernel).
Sure, but that can be an extra option if sgabios adds overhead.
Anyhow, you probably want "-vga none" too.
Paolo
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] Why is SeaBIOS used with -kernel?
2016-04-01 8:51 ` Paolo Bonzini
@ 2016-04-01 8:57 ` Richard W.M. Jones
2016-04-01 9:05 ` Paolo Bonzini
0 siblings, 1 reply; 55+ messages in thread
From: Richard W.M. Jones @ 2016-04-01 8:57 UTC (permalink / raw)
To: Paolo Bonzini
Cc: marc.mari.barcelo, Stefan Hajnoczi, Kevin O'Connor, qemu-devel
On Fri, Apr 01, 2016 at 10:51:31AM +0200, Paolo Bonzini wrote:
>
>
> On 01/04/2016 10:47, Richard W.M. Jones wrote:
> > It's so we can handle error reports. When someone reports that
> > libguestfs "hangs", it's sometimes useful to know if the BIOS was
> > entered or not, since it points the finger at either qemu, BIOS or
> > kernel. (Remember we have to be able to run on a whole variety of
> > Linux distros which often have old/broken/random qemu/bios/kernel).
>
> Sure, but that can be an extra option if sgabios adds overhead.
>
> Anyhow, you probably want "-vga none" too.
That's the qemu option? Currently we use
-nodefconfig -nodefaults -display none
which I assumed would do the same thing (ie. not add any default
devices). Does -vga none do more than this?
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] Why is SeaBIOS used with -kernel?
2016-04-01 8:57 ` Richard W.M. Jones
@ 2016-04-01 9:05 ` Paolo Bonzini
0 siblings, 0 replies; 55+ messages in thread
From: Paolo Bonzini @ 2016-04-01 9:05 UTC (permalink / raw)
To: Richard W.M. Jones
Cc: marc.mari.barcelo, Stefan Hajnoczi, Kevin O'Connor, qemu-devel
On 01/04/2016 10:57, Richard W.M. Jones wrote:
> That's the qemu option? Currently we use
> -nodefconfig -nodefaults -display none
> which I assumed would do the same thing (ie. not add any default
> devices). Does -vga none do more than this?
No, I missed the -nodefaults.
Paolo
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] Why is SeaBIOS used with -kernel?
2016-04-01 8:44 ` Richard W.M. Jones
2016-04-01 8:47 ` Paolo Bonzini
@ 2016-04-01 9:16 ` Dr. David Alan Gilbert
2016-04-01 9:18 ` Gerd Hoffmann
2016-04-01 14:58 ` Kevin O'Connor
3 siblings, 0 replies; 55+ messages in thread
From: Dr. David Alan Gilbert @ 2016-04-01 9:16 UTC (permalink / raw)
To: Richard W.M. Jones
Cc: marc.mari.barcelo, Paolo Bonzini, Kevin O'Connor, qemu-devel,
Stefan Hajnoczi
* Richard W.M. Jones (rjones@redhat.com) wrote:
> On Fri, Apr 01, 2016 at 10:24:37AM +0200, Paolo Bonzini wrote:
> > On 01/04/2016 10:14, Richard W.M. Jones wrote:
> > > Found it: only CONFIG_MPTABLE=y was necessary. It boots with:
> > >
> > > # CONFIG_PIRTABLE is not set
> > > CONFIG_MPTABLE=y
> > > # CONFIG_SMBIOS is not set
> > > # CONFIG_ACPI is not set
> >
> > If you add all three it should not give any slowdown and will provide
> > full hardware features to the kernel. qboot does ACPI and PCI bus
> > assignment (it doesn't do SMBIOS because I got bored debugging it. :))
>
> Enabling all 4 adds about 2ms.
>
> However the overhead of SeaBIOS is still down from 68ms to 18ms
> (4.0% of total boot time down to 1.1%) so it's still a big gain.
>
> I wonder how we can make use of this in qemu and downstream distros?
> Can we have a bios-min.bin which is used with -kernel boots?
Could we pass a flag at runtime that gets the standard image to skip a lot
of the stuff you don't want?
Or is there anything else qemu could provide (e.g. a fast way to get
to PCI config space?)
Dave
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] Why is SeaBIOS used with -kernel?
2016-04-01 8:44 ` Richard W.M. Jones
2016-04-01 8:47 ` Paolo Bonzini
2016-04-01 9:16 ` Dr. David Alan Gilbert
@ 2016-04-01 9:18 ` Gerd Hoffmann
2016-04-01 10:17 ` Richard W.M. Jones
2016-04-01 14:58 ` Kevin O'Connor
3 siblings, 1 reply; 55+ messages in thread
From: Gerd Hoffmann @ 2016-04-01 9:18 UTC (permalink / raw)
To: Richard W.M. Jones
Cc: marc.mari.barcelo, Paolo Bonzini, Kevin O'Connor, qemu-devel,
Stefan Hajnoczi
Hi,
> I wonder how we can make use of this in qemu and downstream distros?
> Can we have a bios-min.bin which is used with -kernel boots?
We already build two seabios roms: one full featued and one slightly
stripped down to keep it below 128k, for backward compatibility with old
machine types.
Adding a third config for -kernel boot should be easy. For that use
case we can probably also turn on seabios logging to the serial console
and drop sgabios. We don't need input (no boot menu) and we also don't
need to hook into int10 (no grub/ipxe using that for output).
cheers,
Gerd
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] Why is SeaBIOS used with -kernel?
2016-04-01 9:18 ` Gerd Hoffmann
@ 2016-04-01 10:17 ` Richard W.M. Jones
2016-04-01 11:07 ` Gerd Hoffmann
0 siblings, 1 reply; 55+ messages in thread
From: Richard W.M. Jones @ 2016-04-01 10:17 UTC (permalink / raw)
To: Gerd Hoffmann
Cc: marc.mari.barcelo, Paolo Bonzini, Kevin O'Connor, qemu-devel,
Stefan Hajnoczi
On Fri, Apr 01, 2016 at 11:18:30AM +0200, Gerd Hoffmann wrote:
> Hi,
>
> > I wonder how we can make use of this in qemu and downstream distros?
> > Can we have a bios-min.bin which is used with -kernel boots?
>
> We already build two seabios roms: one full featued and one slightly
> stripped down to keep it below 128k, for backward compatibility with old
> machine types.
>
> Adding a third config for -kernel boot should be easy. For that use
> case we can probably also turn on seabios logging to the serial console
> and drop sgabios. We don't need input (no boot menu) and we also don't
> need to hook into int10 (no grub/ipxe using that for output).
SeaBIOS logging is slow (or more likely, serial output is slow).
And sgabios is useful for debugging.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] Why is SeaBIOS used with -kernel?
2016-04-01 10:17 ` Richard W.M. Jones
@ 2016-04-01 11:07 ` Gerd Hoffmann
2016-04-01 11:11 ` Richard W.M. Jones
2016-04-01 15:08 ` Kevin O'Connor
0 siblings, 2 replies; 55+ messages in thread
From: Gerd Hoffmann @ 2016-04-01 11:07 UTC (permalink / raw)
To: Richard W.M. Jones
Cc: marc.mari.barcelo, Paolo Bonzini, Kevin O'Connor, qemu-devel,
Stefan Hajnoczi
On Fr, 2016-04-01 at 11:17 +0100, Richard W.M. Jones wrote:
> On Fri, Apr 01, 2016 at 11:18:30AM +0200, Gerd Hoffmann wrote:
> > Hi,
> >
> > > I wonder how we can make use of this in qemu and downstream distros?
> > > Can we have a bios-min.bin which is used with -kernel boots?
> >
> > We already build two seabios roms: one full featued and one slightly
> > stripped down to keep it below 128k, for backward compatibility with old
> > machine types.
> >
> > Adding a third config for -kernel boot should be easy. For that use
> > case we can probably also turn on seabios logging to the serial console
> > and drop sgabios. We don't need input (no boot menu) and we also don't
> > need to hook into int10 (no grub/ipxe using that for output).
>
> SeaBIOS logging is slow (or more likely, serial output is slow).
> And sgabios is useful for debugging.
Ah, I see. debuglevel=1 prints too much and debuglevel=0 has no logging
at all. We'd need seabios log at least the version banner to serial
even with debuglevel=0 to replace sgabios.
https://www.kraxel.org/cgit/qemu/log/?h=work/stripped-seabios
Not hooked into -kernel yet, so you have to use "-bios bios-kboot.bin".
Comments?
cheers,
Gerd
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] Why is SeaBIOS used with -kernel?
2016-04-01 11:07 ` Gerd Hoffmann
@ 2016-04-01 11:11 ` Richard W.M. Jones
2016-04-01 11:20 ` Richard W.M. Jones
2016-04-01 11:32 ` Gerd Hoffmann
2016-04-01 15:08 ` Kevin O'Connor
1 sibling, 2 replies; 55+ messages in thread
From: Richard W.M. Jones @ 2016-04-01 11:11 UTC (permalink / raw)
To: Gerd Hoffmann
Cc: marc.mari.barcelo, Paolo Bonzini, Kevin O'Connor, qemu-devel,
Stefan Hajnoczi
[-- Attachment #1: Type: text/plain, Size: 1807 bytes --]
On Fri, Apr 01, 2016 at 01:07:55PM +0200, Gerd Hoffmann wrote:
> On Fr, 2016-04-01 at 11:17 +0100, Richard W.M. Jones wrote:
> > On Fri, Apr 01, 2016 at 11:18:30AM +0200, Gerd Hoffmann wrote:
> > > Hi,
> > >
> > > > I wonder how we can make use of this in qemu and downstream distros?
> > > > Can we have a bios-min.bin which is used with -kernel boots?
> > >
> > > We already build two seabios roms: one full featued and one slightly
> > > stripped down to keep it below 128k, for backward compatibility with old
> > > machine types.
> > >
> > > Adding a third config for -kernel boot should be easy. For that use
> > > case we can probably also turn on seabios logging to the serial console
> > > and drop sgabios. We don't need input (no boot menu) and we also don't
> > > need to hook into int10 (no grub/ipxe using that for output).
> >
> > SeaBIOS logging is slow (or more likely, serial output is slow).
> > And sgabios is useful for debugging.
>
> Ah, I see. debuglevel=1 prints too much and debuglevel=0 has no logging
> at all. We'd need seabios log at least the version banner to serial
> even with debuglevel=0 to replace sgabios.
>
> https://www.kraxel.org/cgit/qemu/log/?h=work/stripped-seabios
>
> Not hooked into -kernel yet, so you have to use "-bios bios-kboot.bin".
>
> Comments?
I think we were working on the same thing ... Attached is my
version.
Note that you must enable at least CONFIG_MPTABLE else virtio-scsi
does not work in the guest. I also enabled ACPI & SMBIOS & PIRTABLE.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://libguestfs.org
[-- Attachment #2: 0001-bios-Add-fast-variant-of-SeaBIOS-for-use-with-kernel.patch --]
[-- Type: text/plain, Size: 2625 bytes --]
>From 2c9b45d9d03c05573e1dbfc35e6750b127896be6 Mon Sep 17 00:00:00 2001
From: "Richard W.M. Jones" <rjones@redhat.com>
Date: Fri, 1 Apr 2016 11:35:09 +0100
Subject: [PATCH] bios: Add fast variant of SeaBIOS for use with -kernel on
x86.
This commit adds a fast variant of SeaBIOS called 'bios-fast.bin'.
It's designed to be the fastest (also the smallest, but that's not the
main aim) SeaBIOS that is just enough to boot a Linux kernel using the
-kernel option on i686 and x86_64.
This commit does not modify the -kernel option to use this. You have
to specify it by doing something like this:
-kernel vmlinuz -bios bios-fast.bin
Signed-off-by: Richard W.M. Jones <rjones@redhat.com>
---
Makefile | 3 ++-
roms/Makefile | 4 +++-
roms/config.seabios-fast | 12 ++++++++++++
3 files changed, 17 insertions(+), 2 deletions(-)
create mode 100644 roms/config.seabios-fast
diff --git a/Makefile b/Makefile
index 1d076a9..c4e939d 100644
--- a/Makefile
+++ b/Makefile
@@ -389,7 +389,8 @@ common de-ch es fo fr-ca hu ja mk nl-be pt sl tr \
bepo cz
ifdef INSTALL_BLOBS
-BLOBS=bios.bin bios-256k.bin sgabios.bin vgabios.bin vgabios-cirrus.bin \
+BLOBS=bios.bin bios-256k.bin bios-fast.bin \
+sgabios.bin vgabios.bin vgabios-cirrus.bin \
vgabios-stdvga.bin vgabios-vmware.bin vgabios-qxl.bin vgabios-virtio.bin \
acpi-dsdt.aml \
ppc_rom.bin openbios-sparc32 openbios-sparc64 openbios-ppc QEMU,tcx.bin QEMU,cgthree.bin \
diff --git a/roms/Makefile b/roms/Makefile
index 7bd1252..26b0586 100644
--- a/roms/Makefile
+++ b/roms/Makefile
@@ -61,9 +61,11 @@ default:
@echo " slof -- update slof.bin"
@echo " u-boot.e500 -- update u-boot.e500"
-bios: build-seabios-config-seabios-128k build-seabios-config-seabios-256k
+bios: build-seabios-config-seabios-128k build-seabios-config-seabios-256k \
+ build-seabios-config-seabios-fast
cp seabios/builds/seabios-128k/bios.bin ../pc-bios/bios.bin
cp seabios/builds/seabios-256k/bios.bin ../pc-bios/bios-256k.bin
+ cp seabios/builds/seabios-fast/bios.bin ../pc-bios/bios-fast.bin
seavgabios: $(patsubst %,seavgabios-%,$(vgabios_variants))
diff --git a/roms/config.seabios-fast b/roms/config.seabios-fast
new file mode 100644
index 0000000..98a4c27
--- /dev/null
+++ b/roms/config.seabios-fast
@@ -0,0 +1,12 @@
+# The most fastest SeaBIOS that can boot Linux using -kernel.
+CONFIG_USB=n
+CONFIG_DRIVES=n
+CONFIG_KEYBOARD=n
+CONFIG_MOUSE=n
+CONFIG_WRITABLE_UPPERMEMORY=y
+CONFIG_TCGBIOS=n
+CONFIG_PIRTABLE=y
+CONFIG_MPTABLE=y
+CONFIG_SMBIOS=y
+CONFIG_ACPI=y
+CONFIG_DEBUG_LEVEL=0
--
2.7.4
^ permalink raw reply related [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] Why is SeaBIOS used with -kernel?
2016-04-01 11:11 ` Richard W.M. Jones
@ 2016-04-01 11:20 ` Richard W.M. Jones
2016-04-01 11:21 ` Paolo Bonzini
2016-04-05 4:38 ` Kevin Wolf
2016-04-01 11:32 ` Gerd Hoffmann
1 sibling, 2 replies; 55+ messages in thread
From: Richard W.M. Jones @ 2016-04-01 11:20 UTC (permalink / raw)
To: Gerd Hoffmann
Cc: marc.mari.barcelo, Paolo Bonzini, Kevin O'Connor, qemu-devel,
Stefan Hajnoczi
[-- Attachment #1: Type: text/plain, Size: 697 bytes --]
My patch, plus the configuration and comments from your patch,
combined. Plus I tested it with libguestfs boot-analysis and it works
and is still fast.
Integrating this so it happens automatically when the user adds
-kernel on x86 seems quite complicated. The only way I could do it
was by adding #ifdef defined(__x86_64__) etc to vl.c, which doesn't
seem very nice. The problem is the machine type code doesn't know
that you're using -kernel.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
[-- Attachment #2: 0001-bios-Add-fast-variant-of-SeaBIOS-for-use-with-kernel.patch --]
[-- Type: text/plain, Size: 3017 bytes --]
>From 28a442fdf8036bde075c75088f8dae8d8568243a Mon Sep 17 00:00:00 2001
From: "Richard W.M. Jones" <rjones@redhat.com>
Date: Fri, 1 Apr 2016 11:35:09 +0100
Subject: [PATCH] bios: Add fast variant of SeaBIOS for use with -kernel on
x86.
This commit adds a fast variant of SeaBIOS called 'bios-fast.bin'.
It's designed to be the fastest (also the smallest, but that's not the
main aim) SeaBIOS that is just enough to boot a Linux kernel using the
-kernel option on i686 and x86_64.
This commit does not modify the -kernel option to use this. You have
to specify it by doing something like this:
-kernel vmlinuz -bios bios-fast.bin
Signed-off-by: Richard W.M. Jones <rjones@redhat.com>
---
Makefile | 3 ++-
roms/Makefile | 4 +++-
roms/config.seabios-fast | 32 ++++++++++++++++++++++++++++++++
3 files changed, 37 insertions(+), 2 deletions(-)
create mode 100644 roms/config.seabios-fast
diff --git a/Makefile b/Makefile
index 1d076a9..c4e939d 100644
--- a/Makefile
+++ b/Makefile
@@ -389,7 +389,8 @@ common de-ch es fo fr-ca hu ja mk nl-be pt sl tr \
bepo cz
ifdef INSTALL_BLOBS
-BLOBS=bios.bin bios-256k.bin sgabios.bin vgabios.bin vgabios-cirrus.bin \
+BLOBS=bios.bin bios-256k.bin bios-fast.bin \
+sgabios.bin vgabios.bin vgabios-cirrus.bin \
vgabios-stdvga.bin vgabios-vmware.bin vgabios-qxl.bin vgabios-virtio.bin \
acpi-dsdt.aml \
ppc_rom.bin openbios-sparc32 openbios-sparc64 openbios-ppc QEMU,tcx.bin QEMU,cgthree.bin \
diff --git a/roms/Makefile b/roms/Makefile
index 7bd1252..26b0586 100644
--- a/roms/Makefile
+++ b/roms/Makefile
@@ -61,9 +61,11 @@ default:
@echo " slof -- update slof.bin"
@echo " u-boot.e500 -- update u-boot.e500"
-bios: build-seabios-config-seabios-128k build-seabios-config-seabios-256k
+bios: build-seabios-config-seabios-128k build-seabios-config-seabios-256k \
+ build-seabios-config-seabios-fast
cp seabios/builds/seabios-128k/bios.bin ../pc-bios/bios.bin
cp seabios/builds/seabios-256k/bios.bin ../pc-bios/bios-256k.bin
+ cp seabios/builds/seabios-fast/bios.bin ../pc-bios/bios-fast.bin
seavgabios: $(patsubst %,seavgabios-%,$(vgabios_variants))
diff --git a/roms/config.seabios-fast b/roms/config.seabios-fast
new file mode 100644
index 0000000..fbb1ef8
--- /dev/null
+++ b/roms/config.seabios-fast
@@ -0,0 +1,32 @@
+# The fastest SeaBIOS that can boot Linux using -kernel.
+
+# general stuff
+CONFIG_QEMU=y
+CONFIG_ROM_SIZE=128
+CONFIG_XEN=n
+CONFIG_THREADS=n
+CONFIG_WRITABLE_UPPERMEMORY=y
+
+# no input, no boot menu
+CONFIG_MOUSE=n
+CONFIG_KEYBOARD=n
+CONFIG_BOOTMENU=n
+CONFIG_BOOTSPLASH=n
+
+# hardware support we don't need
+CONFIG_LPT=n
+CONFIG_SERIAL=n
+CONFIG_USB=n
+CONFIG_DRIVES=n
+CONFIG_TCGBIOS=n
+CONFIG_VGAHOOKS=n
+
+# MPTABLE is required by Linux kernel, the others add only a
+# couple of milliseconds so we might as well have them
+CONFIG_PIRTABLE=y
+CONFIG_MPTABLE=y
+CONFIG_SMBIOS=y
+CONFIG_ACPI=y
+
+# no logging
+CONFIG_DEBUG_LEVEL=0
--
2.7.4
^ permalink raw reply related [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] Why is SeaBIOS used with -kernel?
2016-04-01 11:20 ` Richard W.M. Jones
@ 2016-04-01 11:21 ` Paolo Bonzini
2016-04-01 11:26 ` Richard W.M. Jones
2016-04-05 4:38 ` Kevin Wolf
1 sibling, 1 reply; 55+ messages in thread
From: Paolo Bonzini @ 2016-04-01 11:21 UTC (permalink / raw)
To: Richard W.M. Jones, Gerd Hoffmann
Cc: marc.mari.barcelo, Stefan Hajnoczi, Kevin O'Connor, qemu-devel
On 01/04/2016 13:20, Richard W.M. Jones wrote:
> +# MPTABLE is required by Linux kernel, the others add only a
> +# couple of milliseconds so we might as well have them
> +CONFIG_PIRTABLE=y
> +CONFIG_MPTABLE=y
> +CONFIG_SMBIOS=y
> +CONFIG_ACPI=y
> +
MPTABLE is only required is you don't have ACPI.
Paolo
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] Why is SeaBIOS used with -kernel?
2016-04-01 11:21 ` Paolo Bonzini
@ 2016-04-01 11:26 ` Richard W.M. Jones
0 siblings, 0 replies; 55+ messages in thread
From: Richard W.M. Jones @ 2016-04-01 11:26 UTC (permalink / raw)
To: Paolo Bonzini
Cc: marc.mari.barcelo, Stefan Hajnoczi, Kevin O'Connor,
Gerd Hoffmann, qemu-devel
On Fri, Apr 01, 2016 at 01:21:38PM +0200, Paolo Bonzini wrote:
>
>
> On 01/04/2016 13:20, Richard W.M. Jones wrote:
> > +# MPTABLE is required by Linux kernel, the others add only a
> > +# couple of milliseconds so we might as well have them
> > +CONFIG_PIRTABLE=y
> > +CONFIG_MPTABLE=y
> > +CONFIG_SMBIOS=y
> > +CONFIG_ACPI=y
> > +
>
> MPTABLE is only required is you don't have ACPI.
True .. however for speed reasons libguestfs uses acpi=off. It saves
us about 190 ms. So we need MPTABLE.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] Why is SeaBIOS used with -kernel?
2016-04-01 11:11 ` Richard W.M. Jones
2016-04-01 11:20 ` Richard W.M. Jones
@ 2016-04-01 11:32 ` Gerd Hoffmann
2016-04-01 11:49 ` Richard W.M. Jones
1 sibling, 1 reply; 55+ messages in thread
From: Gerd Hoffmann @ 2016-04-01 11:32 UTC (permalink / raw)
To: Richard W.M. Jones
Cc: marc.mari.barcelo, Paolo Bonzini, Kevin O'Connor, qemu-devel,
Stefan Hajnoczi
Hi,
> I think we were working on the same thing ... Attached is my
> version.
>
> Note that you must enable at least CONFIG_MPTABLE else virtio-scsi
> does not work in the guest. I also enabled ACPI & SMBIOS & PIRTABLE.
They are enabled by default, no need to explicitly say so ;)
cheers,
Gerd
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] Why is SeaBIOS used with -kernel?
2016-04-01 11:32 ` Gerd Hoffmann
@ 2016-04-01 11:49 ` Richard W.M. Jones
2016-04-01 15:35 ` Kevin O'Connor
0 siblings, 1 reply; 55+ messages in thread
From: Richard W.M. Jones @ 2016-04-01 11:49 UTC (permalink / raw)
To: Gerd Hoffmann
Cc: marc.mari.barcelo, Paolo Bonzini, Kevin O'Connor, qemu-devel,
Stefan Hajnoczi
[-- Attachment #1: Type: text/plain, Size: 1323 bytes --]
On Fri, Apr 01, 2016 at 01:32:51PM +0200, Gerd Hoffmann wrote:
> Hi,
>
> > I think we were working on the same thing ... Attached is my
> > version.
> >
> > Note that you must enable at least CONFIG_MPTABLE else virtio-scsi
> > does not work in the guest. I also enabled ACPI & SMBIOS & PIRTABLE.
>
> They are enabled by default, no need to explicitly say so ;)
So they are. Here's a v3 patch.
I also retested everything from scratch. Previously I was testing the
stock SeaBIOS bios.bin shipped with qemu vs the fast config. However
that has the possible problem that I was testing two slightly
different versions of SeaBIOS (whatever version qemu ships vs
upstream).
Testing from scratch, using upstream SeaBIOS in both cases, there's
still a significant benefit. SeaBIOS overhead goes from 63 ms down to
19 ms (saving 44 ms).
Overall the proportion of boot time of the libguestfs appliance
attributed to SeaBIOS drops from 3.7% to 1.1% (but note this is with
libguestfs & kernel debugging enabled -- for real users there'd be a
much larger percentage drop).
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
[-- Attachment #2: 0001-bios-Add-fast-variant-of-SeaBIOS-for-use-with-kernel.patch --]
[-- Type: text/plain, Size: 2821 bytes --]
>From 8cdf91f13949ab46c6a5804b968400d404c4e00e Mon Sep 17 00:00:00 2001
From: "Richard W.M. Jones" <rjones@redhat.com>
Date: Fri, 1 Apr 2016 11:35:09 +0100
Subject: [PATCH] bios: Add fast variant of SeaBIOS for use with -kernel on
x86.
This commit adds a fast variant of SeaBIOS called 'bios-fast.bin'.
It's designed to be the fastest (also the smallest, but that's not the
main aim) SeaBIOS that is just enough to boot a Linux kernel using the
-kernel option on i686 and x86_64.
This commit does not modify the -kernel option to use this. You have
to specify it by doing something like this:
-kernel vmlinuz -bios bios-fast.bin
Signed-off-by: Richard W.M. Jones <rjones@redhat.com>
---
Makefile | 3 ++-
roms/Makefile | 4 +++-
roms/config.seabios-fast | 25 +++++++++++++++++++++++++
3 files changed, 30 insertions(+), 2 deletions(-)
create mode 100644 roms/config.seabios-fast
diff --git a/Makefile b/Makefile
index 1d076a9..c4e939d 100644
--- a/Makefile
+++ b/Makefile
@@ -389,7 +389,8 @@ common de-ch es fo fr-ca hu ja mk nl-be pt sl tr \
bepo cz
ifdef INSTALL_BLOBS
-BLOBS=bios.bin bios-256k.bin sgabios.bin vgabios.bin vgabios-cirrus.bin \
+BLOBS=bios.bin bios-256k.bin bios-fast.bin \
+sgabios.bin vgabios.bin vgabios-cirrus.bin \
vgabios-stdvga.bin vgabios-vmware.bin vgabios-qxl.bin vgabios-virtio.bin \
acpi-dsdt.aml \
ppc_rom.bin openbios-sparc32 openbios-sparc64 openbios-ppc QEMU,tcx.bin QEMU,cgthree.bin \
diff --git a/roms/Makefile b/roms/Makefile
index 7bd1252..26b0586 100644
--- a/roms/Makefile
+++ b/roms/Makefile
@@ -61,9 +61,11 @@ default:
@echo " slof -- update slof.bin"
@echo " u-boot.e500 -- update u-boot.e500"
-bios: build-seabios-config-seabios-128k build-seabios-config-seabios-256k
+bios: build-seabios-config-seabios-128k build-seabios-config-seabios-256k \
+ build-seabios-config-seabios-fast
cp seabios/builds/seabios-128k/bios.bin ../pc-bios/bios.bin
cp seabios/builds/seabios-256k/bios.bin ../pc-bios/bios-256k.bin
+ cp seabios/builds/seabios-fast/bios.bin ../pc-bios/bios-fast.bin
seavgabios: $(patsubst %,seavgabios-%,$(vgabios_variants))
diff --git a/roms/config.seabios-fast b/roms/config.seabios-fast
new file mode 100644
index 0000000..f035b49
--- /dev/null
+++ b/roms/config.seabios-fast
@@ -0,0 +1,25 @@
+# The fastest SeaBIOS that can boot Linux using -kernel.
+
+# general stuff
+CONFIG_QEMU=y
+CONFIG_ROM_SIZE=128
+CONFIG_XEN=n
+CONFIG_THREADS=n
+CONFIG_WRITABLE_UPPERMEMORY=y
+
+# no input, no boot menu
+CONFIG_MOUSE=n
+CONFIG_KEYBOARD=n
+CONFIG_BOOTMENU=n
+CONFIG_BOOTSPLASH=n
+
+# hardware support we don't need
+CONFIG_LPT=n
+CONFIG_SERIAL=n
+CONFIG_USB=n
+CONFIG_DRIVES=n
+CONFIG_TCGBIOS=n
+CONFIG_VGAHOOKS=n
+
+# no logging
+CONFIG_DEBUG_LEVEL=0
--
2.7.4
^ permalink raw reply related [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] Why is SeaBIOS used with -kernel?
2016-04-01 8:44 ` Richard W.M. Jones
` (2 preceding siblings ...)
2016-04-01 9:18 ` Gerd Hoffmann
@ 2016-04-01 14:58 ` Kevin O'Connor
2016-04-01 15:06 ` Richard W.M. Jones
3 siblings, 1 reply; 55+ messages in thread
From: Kevin O'Connor @ 2016-04-01 14:58 UTC (permalink / raw)
To: Richard W.M. Jones
Cc: marc.mari.barcelo, Paolo Bonzini, qemu-devel, Stefan Hajnoczi
On Fri, Apr 01, 2016 at 09:44:56AM +0100, Richard W.M. Jones wrote:
> On Fri, Apr 01, 2016 at 10:24:37AM +0200, Paolo Bonzini wrote:
> > On 01/04/2016 10:14, Richard W.M. Jones wrote:
> > > Found it: only CONFIG_MPTABLE=y was necessary. It boots with:
> > >
> > > # CONFIG_PIRTABLE is not set
> > > CONFIG_MPTABLE=y
> > > # CONFIG_SMBIOS is not set
> > > # CONFIG_ACPI is not set
> >
> > If you add all three it should not give any slowdown and will provide
> > full hardware features to the kernel. qboot does ACPI and PCI bus
> > assignment (it doesn't do SMBIOS because I got bored debugging it. :))
>
> Enabling all 4 adds about 2ms.
CONFIG_SMBIOS and CONFIG_ACPI only control the legacy internal bios
tables. One would disable CONFIG_FW_ROMFILE_LOAD to disable the newer
ACPI tables; there is no config option currently to disable the newer
smbios tables.
These config names are a bit misleading, so they probably should be
changed in seabios.
I didn't expect disabling the above options to do anything besides
reduce the size of the seabios binary, so I'm a bit suprised it saved
2ms. Did you have something on your qemu command-line to avoid
generating acpi/smbios tables?
-Kevin
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] Why is SeaBIOS used with -kernel?
2016-04-01 14:58 ` Kevin O'Connor
@ 2016-04-01 15:06 ` Richard W.M. Jones
2016-04-01 15:14 ` Kevin O'Connor
0 siblings, 1 reply; 55+ messages in thread
From: Richard W.M. Jones @ 2016-04-01 15:06 UTC (permalink / raw)
To: Kevin O'Connor
Cc: marc.mari.barcelo, Paolo Bonzini, qemu-devel, Stefan Hajnoczi
On Fri, Apr 01, 2016 at 10:58:19AM -0400, Kevin O'Connor wrote:
> On Fri, Apr 01, 2016 at 09:44:56AM +0100, Richard W.M. Jones wrote:
> > On Fri, Apr 01, 2016 at 10:24:37AM +0200, Paolo Bonzini wrote:
> > > On 01/04/2016 10:14, Richard W.M. Jones wrote:
> > > > Found it: only CONFIG_MPTABLE=y was necessary. It boots with:
> > > >
> > > > # CONFIG_PIRTABLE is not set
> > > > CONFIG_MPTABLE=y
> > > > # CONFIG_SMBIOS is not set
> > > > # CONFIG_ACPI is not set
> > >
> > > If you add all three it should not give any slowdown and will provide
> > > full hardware features to the kernel. qboot does ACPI and PCI bus
> > > assignment (it doesn't do SMBIOS because I got bored debugging it. :))
> >
> > Enabling all 4 adds about 2ms.
>
> CONFIG_SMBIOS and CONFIG_ACPI only control the legacy internal bios
> tables. One would disable CONFIG_FW_ROMFILE_LOAD to disable the newer
> ACPI tables; there is no config option currently to disable the newer
> smbios tables.
>
> These config names are a bit misleading, so they probably should be
> changed in seabios.
>
> I didn't expect disabling the above options to do anything besides
> reduce the size of the seabios binary, so I'm a bit suprised it saved
> 2ms. Did you have something on your qemu command-line to avoid
> generating acpi/smbios tables?
The standard deviation of that number over 5 runs was 1ms, so I'm
somewhat confident the 2ms is measuring something real. In the grand
scheme of things it doesn't matter at all.
I'm not using any qemu command line options related to acpi or smbios.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] Why is SeaBIOS used with -kernel?
2016-04-01 11:07 ` Gerd Hoffmann
2016-04-01 11:11 ` Richard W.M. Jones
@ 2016-04-01 15:08 ` Kevin O'Connor
1 sibling, 0 replies; 55+ messages in thread
From: Kevin O'Connor @ 2016-04-01 15:08 UTC (permalink / raw)
To: Gerd Hoffmann
Cc: marc.mari.barcelo, Paolo Bonzini, qemu-devel, Richard W.M. Jones,
Stefan Hajnoczi
On Fri, Apr 01, 2016 at 01:07:55PM +0200, Gerd Hoffmann wrote:
> On Fr, 2016-04-01 at 11:17 +0100, Richard W.M. Jones wrote:
> > On Fri, Apr 01, 2016 at 11:18:30AM +0200, Gerd Hoffmann wrote:
> > > Hi,
> > >
> > > > I wonder how we can make use of this in qemu and downstream distros?
> > > > Can we have a bios-min.bin which is used with -kernel boots?
> > >
> > > We already build two seabios roms: one full featued and one slightly
> > > stripped down to keep it below 128k, for backward compatibility with old
> > > machine types.
> > >
> > > Adding a third config for -kernel boot should be easy. For that use
> > > case we can probably also turn on seabios logging to the serial console
> > > and drop sgabios. We don't need input (no boot menu) and we also don't
> > > need to hook into int10 (no grub/ipxe using that for output).
> >
> > SeaBIOS logging is slow (or more likely, serial output is slow).
> > And sgabios is useful for debugging.
>
> Ah, I see. debuglevel=1 prints too much and debuglevel=0 has no logging
> at all. We'd need seabios log at least the version banner to serial
> even with debuglevel=0 to replace sgabios.
The debug level of messages in SeaBIOS are a bit haphazard today.
I think it would be a good idea to document what types of messages go
in each debug level and then update the current debug messages to fit
that description. It sounds like level=1 is too verbose today.
-Kevin
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] Why is SeaBIOS used with -kernel?
2016-04-01 15:06 ` Richard W.M. Jones
@ 2016-04-01 15:14 ` Kevin O'Connor
0 siblings, 0 replies; 55+ messages in thread
From: Kevin O'Connor @ 2016-04-01 15:14 UTC (permalink / raw)
To: Richard W.M. Jones
Cc: marc.mari.barcelo, Paolo Bonzini, qemu-devel, Stefan Hajnoczi
On Fri, Apr 01, 2016 at 04:06:23PM +0100, Richard W.M. Jones wrote:
> On Fri, Apr 01, 2016 at 10:58:19AM -0400, Kevin O'Connor wrote:
> > On Fri, Apr 01, 2016 at 09:44:56AM +0100, Richard W.M. Jones wrote:
> > > On Fri, Apr 01, 2016 at 10:24:37AM +0200, Paolo Bonzini wrote:
> > > > On 01/04/2016 10:14, Richard W.M. Jones wrote:
> > > > > Found it: only CONFIG_MPTABLE=y was necessary. It boots with:
> > > > >
> > > > > # CONFIG_PIRTABLE is not set
> > > > > CONFIG_MPTABLE=y
> > > > > # CONFIG_SMBIOS is not set
> > > > > # CONFIG_ACPI is not set
> > > >
> > > > If you add all three it should not give any slowdown and will provide
> > > > full hardware features to the kernel. qboot does ACPI and PCI bus
> > > > assignment (it doesn't do SMBIOS because I got bored debugging it. :))
> > >
> > > Enabling all 4 adds about 2ms.
> >
> > CONFIG_SMBIOS and CONFIG_ACPI only control the legacy internal bios
> > tables. One would disable CONFIG_FW_ROMFILE_LOAD to disable the newer
> > ACPI tables; there is no config option currently to disable the newer
> > smbios tables.
> >
> > These config names are a bit misleading, so they probably should be
> > changed in seabios.
> >
> > I didn't expect disabling the above options to do anything besides
> > reduce the size of the seabios binary, so I'm a bit suprised it saved
> > 2ms. Did you have something on your qemu command-line to avoid
> > generating acpi/smbios tables?
>
> The standard deviation of that number over 5 runs was 1ms, so I'm
> somewhat confident the 2ms is measuring something real. In the grand
> scheme of things it doesn't matter at all.
>
> I'm not using any qemu command line options related to acpi or smbios.
Okay - interesting.
Considering you have acpi=off in linux, you might want to try timing
with CONFIG_ACPI, CONFIG_SMBIOS, and CONFIG_FW_ROMFILE_LOAD all
disabled. The acpi romfile loading stuff takes 4ms in my tests.
It's not clear to me that disabling acpi is a good plan, but it can't
hurt to time it.
-Kevin
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] Why is SeaBIOS used with -kernel?
2016-04-01 11:49 ` Richard W.M. Jones
@ 2016-04-01 15:35 ` Kevin O'Connor
2016-04-01 16:03 ` Paolo Bonzini
2016-04-01 18:41 ` Richard W.M. Jones
0 siblings, 2 replies; 55+ messages in thread
From: Kevin O'Connor @ 2016-04-01 15:35 UTC (permalink / raw)
To: Richard W.M. Jones
Cc: marc.mari.barcelo, Paolo Bonzini, qemu-devel, Gerd Hoffmann,
Stefan Hajnoczi
On Fri, Apr 01, 2016 at 12:49:47PM +0100, Richard W.M. Jones wrote:
> On Fri, Apr 01, 2016 at 01:32:51PM +0200, Gerd Hoffmann wrote:
> > > I think we were working on the same thing ... Attached is my
> > > version.
> > >
> > > Note that you must enable at least CONFIG_MPTABLE else virtio-scsi
> > > does not work in the guest. I also enabled ACPI & SMBIOS & PIRTABLE.
> >
> > They are enabled by default, no need to explicitly say so ;)
>
> So they are. Here's a v3 patch.
>
> I also retested everything from scratch. Previously I was testing the
> stock SeaBIOS bios.bin shipped with qemu vs the fast config. However
> that has the possible problem that I was testing two slightly
> different versions of SeaBIOS (whatever version qemu ships vs
> upstream).
>
> Testing from scratch, using upstream SeaBIOS in both cases, there's
> still a significant benefit. SeaBIOS overhead goes from 63 ms down to
> 19 ms (saving 44 ms).
>
> Overall the proportion of boot time of the libguestfs appliance
> attributed to SeaBIOS drops from 3.7% to 1.1% (but note this is with
> libguestfs & kernel debugging enabled -- for real users there'd be a
> much larger percentage drop).
>
> Rich.
>
> --
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> virt-builder quickly builds VMs from scratch
> http://libguestfs.org/virt-builder.1.html
> From 8cdf91f13949ab46c6a5804b968400d404c4e00e Mon Sep 17 00:00:00 2001
> From: "Richard W.M. Jones" <rjones@redhat.com>
> Date: Fri, 1 Apr 2016 11:35:09 +0100
> Subject: [PATCH] bios: Add fast variant of SeaBIOS for use with -kernel on
> x86.
>
> This commit adds a fast variant of SeaBIOS called 'bios-fast.bin'.
>
> It's designed to be the fastest (also the smallest, but that's not the
> main aim) SeaBIOS that is just enough to boot a Linux kernel using the
> -kernel option on i686 and x86_64.
>
> This commit does not modify the -kernel option to use this. You have
> to specify it by doing something like this:
>
> -kernel vmlinuz -bios bios-fast.bin
It's possible to build a third binary, but that seems like it would be
a bit annoying for distributions. I think most of the benefit could
be obtained by just adding a flag to seabios to have it skip device
driver initialization. That's where the majority of the time saved is
from.
[...]
> --- /dev/null
> +++ b/roms/config.seabios-fast
> @@ -0,0 +1,25 @@
> +# The fastest SeaBIOS that can boot Linux using -kernel.
> +
> +# general stuff
> +CONFIG_QEMU=y
> +CONFIG_ROM_SIZE=128
Why force a size of 128K - I would think 64K would be fine.
> +CONFIG_XEN=n
> +CONFIG_THREADS=n
I doubt either of these two would change timing at all. There's no
harm in disabling CONFIG_XEN, but I would not recommend disabling
CONFIG_THREADS.
> +CONFIG_WRITABLE_UPPERMEMORY=y
> +
> +# no input, no boot menu
> +CONFIG_MOUSE=n
> +CONFIG_KEYBOARD=n
[...]
> +CONFIG_DRIVES=n
I would not recommended disabling CONFIG_MOUSE, CONFIG_KEYBOARD,
CONFIG_DRIVES - I only had those in my config so as to avoid having to
specify all the device drivers. Ideally these would remain on and the
individual device drivers would be disabled.
> +CONFIG_BOOTMENU=n
> +CONFIG_BOOTSPLASH=n
These two should have no impact on timing at all.
> +
> +# hardware support we don't need
> +CONFIG_LPT=n
> +CONFIG_SERIAL=n
> +CONFIG_USB=n
[...]
> +CONFIG_TCGBIOS=n
> +CONFIG_VGAHOOKS=n
> +
> +# no logging
> +CONFIG_DEBUG_LEVEL=0
If you really want to go all out on timing tests, you could disable
CONFIG_USE_SMM, and CONFIG_FW_ROMFILE_LOAD. Disabling
CONFIG_RELOCATE_INIT may help, but probably not.
-Kevin
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] Why is SeaBIOS used with -kernel?
2016-04-01 15:35 ` Kevin O'Connor
@ 2016-04-01 16:03 ` Paolo Bonzini
2016-04-01 18:41 ` Richard W.M. Jones
1 sibling, 0 replies; 55+ messages in thread
From: Paolo Bonzini @ 2016-04-01 16:03 UTC (permalink / raw)
To: Kevin O'Connor, Richard W.M. Jones
Cc: marc.mari.barcelo, Stefan Hajnoczi, qemu-devel, Gerd Hoffmann
On 01/04/2016 17:35, Kevin O'Connor wrote:
> It's possible to build a third binary, but that seems like it would be
> a bit annoying for distributions.
I don't think that would be a problem. Fedora is already building 4
binaries (128k, 256k, CSM, coreboot), adding a fifth is not a big deal.
Paolo
> I think most of the benefit could
> be obtained by just adding a flag to seabios to have it skip device
> driver initialization. That's where the majority of the time saved is
> from.
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] Why is SeaBIOS used with -kernel?
2016-04-01 15:35 ` Kevin O'Connor
2016-04-01 16:03 ` Paolo Bonzini
@ 2016-04-01 18:41 ` Richard W.M. Jones
2016-04-01 18:59 ` Richard W.M. Jones
2016-04-01 20:05 ` Kevin O'Connor
1 sibling, 2 replies; 55+ messages in thread
From: Richard W.M. Jones @ 2016-04-01 18:41 UTC (permalink / raw)
To: Kevin O'Connor
Cc: marc.mari.barcelo, Paolo Bonzini, qemu-devel, Gerd Hoffmann,
Stefan Hajnoczi
On Fri, Apr 01, 2016 at 11:35:40AM -0400, Kevin O'Connor wrote:
> > +# general stuff
> > +CONFIG_QEMU=y
> > +CONFIG_ROM_SIZE=128
>
> Why force a size of 128K - I would think 64K would be fine.
Agreed. Setting this to =0 seems the best thing, and it does fit fine
inside 64K.
> > +# no input, no boot menu
> > +CONFIG_MOUSE=n
> > +CONFIG_KEYBOARD=n
> [...]
> > +CONFIG_DRIVES=n
>
> I would not recommended disabling CONFIG_MOUSE, CONFIG_KEYBOARD,
> CONFIG_DRIVES - I only had those in my config so as to avoid having to
> specify all the device drivers. Ideally these would remain on and the
> individual device drivers would be disabled.
We are always use this in a virtual appliance. Interaction with the
user is both impossible and undesirable. It either boots or not, and
the whole appliance is discarded in seconds. We're always using
-kernel with this SeaBIOS build, so probing drives is never needed.
Below are some benchmarks of the other things you mentioned. These
are complete appliance boot-to-shutdown times [*not* just SeaBIOS].
All debugging has been disabled, and I'm using a slightly different
kernel version, so these runs are not comparable to earlier results I
posted. All times are the mean of 10 runs. The ± number is 1
standard deviation from the mean.
In my estimation only CONFIG_FW_ROMFILE_LOAD=n seems to make a
measurable difference.
----------------------------------------------------------------------
Ordinary qemu SeaBIOS configuration
Result: 1227.5ms ±7.7ms
-bios boot-fast.bin, as per my previous patch
Result: 1113.7ms ±6.4ms
Leaving CONFIG_XEN and CONFIG_THREADS at default settings
Result: 1111.2ms ±3.8ms
CONFIG_USE_SMM=n
Result: 1116.0ms ±5.0ms
CONFIG_FW_ROMFILE_LOAD=n
Result: 1106.6ms ±5.0ms
CONFIG_RELOCATE_INIT=n
Result: 1104.7ms ±11.2ms
----------------------------------------------------------------------
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://libguestfs.org
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] Why is SeaBIOS used with -kernel?
2016-04-01 18:41 ` Richard W.M. Jones
@ 2016-04-01 18:59 ` Richard W.M. Jones
2016-04-01 19:04 ` Kevin O'Connor
2016-04-01 20:05 ` Kevin O'Connor
1 sibling, 1 reply; 55+ messages in thread
From: Richard W.M. Jones @ 2016-04-01 18:59 UTC (permalink / raw)
To: Kevin O'Connor
Cc: marc.mari.barcelo, Paolo Bonzini, Stefan Hajnoczi, qemu-devel,
Gerd Hoffmann
On Fri, Apr 01, 2016 at 07:41:31PM +0100, Richard W.M. Jones wrote:
> Below are some benchmarks of the other things you mentioned. These
> are complete appliance boot-to-shutdown times [*not* just SeaBIOS].
> All debugging has been disabled, and I'm using a slightly different
> kernel version, so these runs are not comparable to earlier results I
> posted. All times are the mean of 10 runs. The ± number is 1
> standard deviation from the mean.
>
> In my estimation only CONFIG_FW_ROMFILE_LOAD=n seems to make a
> measurable difference.
>
> ----------------------------------------------------------------------
> Ordinary qemu SeaBIOS configuration
> Result: 1227.5ms ±7.7ms
>
> -bios boot-fast.bin, as per my previous patch
> Result: 1113.7ms ±6.4ms
>
> Leaving CONFIG_XEN and CONFIG_THREADS at default settings
> Result: 1111.2ms ±3.8ms
>
> CONFIG_USE_SMM=n
> Result: 1116.0ms ±5.0ms
>
> CONFIG_FW_ROMFILE_LOAD=n
> Result: 1106.6ms ±5.0ms
>
> CONFIG_RELOCATE_INIT=n
> Result: 1104.7ms ±11.2ms
> ----------------------------------------------------------------------
Actually, CONFIG_RELOCATE_INIT=n looks like it is doing something, but
the error bars are quite large.
Here's another one that makes a difference:
CONFIG_BOOTORDER=n
Result: 1099.5ms ±3.7ms
(Since we're using -kernel, we don't care about bootorder)
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] Why is SeaBIOS used with -kernel?
2016-04-01 18:59 ` Richard W.M. Jones
@ 2016-04-01 19:04 ` Kevin O'Connor
2016-04-01 19:10 ` Richard W.M. Jones
0 siblings, 1 reply; 55+ messages in thread
From: Kevin O'Connor @ 2016-04-01 19:04 UTC (permalink / raw)
To: Richard W.M. Jones
Cc: marc.mari.barcelo, Paolo Bonzini, Stefan Hajnoczi, qemu-devel,
Gerd Hoffmann
On Fri, Apr 01, 2016 at 07:59:02PM +0100, Richard W.M. Jones wrote:
> On Fri, Apr 01, 2016 at 07:41:31PM +0100, Richard W.M. Jones wrote:
> > Below are some benchmarks of the other things you mentioned. These
> > are complete appliance boot-to-shutdown times [*not* just SeaBIOS].
> > All debugging has been disabled, and I'm using a slightly different
> > kernel version, so these runs are not comparable to earlier results I
> > posted. All times are the mean of 10 runs. The ± number is 1
> > standard deviation from the mean.
> >
> > In my estimation only CONFIG_FW_ROMFILE_LOAD=n seems to make a
> > measurable difference.
> >
> > ----------------------------------------------------------------------
> > Ordinary qemu SeaBIOS configuration
> > Result: 1227.5ms ±7.7ms
> >
> > -bios boot-fast.bin, as per my previous patch
> > Result: 1113.7ms ±6.4ms
> >
> > Leaving CONFIG_XEN and CONFIG_THREADS at default settings
> > Result: 1111.2ms ±3.8ms
> >
> > CONFIG_USE_SMM=n
> > Result: 1116.0ms ±5.0ms
> >
> > CONFIG_FW_ROMFILE_LOAD=n
> > Result: 1106.6ms ±5.0ms
> >
> > CONFIG_RELOCATE_INIT=n
> > Result: 1104.7ms ±11.2ms
> > ----------------------------------------------------------------------
>
> Actually, CONFIG_RELOCATE_INIT=n looks like it is doing something, but
> the error bars are quite large.
>
> Here's another one that makes a difference:
>
> CONFIG_BOOTORDER=n
> Result: 1099.5ms ±3.7ms
Are you sure you had CONFIG_DEBUG_LEVEL=0? Otherwise, it doesn't make
sense that disabling CONFIG_BOOTORDER=n would change the boot time.
Disabling CONFIG_DEBUG_SERIAL is not enough, because SeaBIOS also
writes to port 0x402 as an internal debugging mechanism.
-Kevin
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] Why is SeaBIOS used with -kernel?
2016-04-01 19:04 ` Kevin O'Connor
@ 2016-04-01 19:10 ` Richard W.M. Jones
2016-04-01 19:15 ` Richard W.M. Jones
0 siblings, 1 reply; 55+ messages in thread
From: Richard W.M. Jones @ 2016-04-01 19:10 UTC (permalink / raw)
To: Kevin O'Connor
Cc: marc.mari.barcelo, Paolo Bonzini, Gerd Hoffmann, qemu-devel,
Stefan Hajnoczi
On Fri, Apr 01, 2016 at 03:04:15PM -0400, Kevin O'Connor wrote:
> On Fri, Apr 01, 2016 at 07:59:02PM +0100, Richard W.M. Jones wrote:
> > On Fri, Apr 01, 2016 at 07:41:31PM +0100, Richard W.M. Jones wrote:
> > > Below are some benchmarks of the other things you mentioned. These
> > > are complete appliance boot-to-shutdown times [*not* just SeaBIOS].
> > > All debugging has been disabled, and I'm using a slightly different
> > > kernel version, so these runs are not comparable to earlier results I
> > > posted. All times are the mean of 10 runs. The ± number is 1
> > > standard deviation from the mean.
> > >
> > > In my estimation only CONFIG_FW_ROMFILE_LOAD=n seems to make a
> > > measurable difference.
> > >
> > > ----------------------------------------------------------------------
> > > Ordinary qemu SeaBIOS configuration
> > > Result: 1227.5ms ±7.7ms
> > >
> > > -bios boot-fast.bin, as per my previous patch
> > > Result: 1113.7ms ±6.4ms
> > >
> > > Leaving CONFIG_XEN and CONFIG_THREADS at default settings
> > > Result: 1111.2ms ±3.8ms
> > >
> > > CONFIG_USE_SMM=n
> > > Result: 1116.0ms ±5.0ms
> > >
> > > CONFIG_FW_ROMFILE_LOAD=n
> > > Result: 1106.6ms ±5.0ms
> > >
> > > CONFIG_RELOCATE_INIT=n
> > > Result: 1104.7ms ±11.2ms
> > > ----------------------------------------------------------------------
> >
> > Actually, CONFIG_RELOCATE_INIT=n looks like it is doing something, but
> > the error bars are quite large.
> >
> > Here's another one that makes a difference:
> >
> > CONFIG_BOOTORDER=n
> > Result: 1099.5ms ±3.7ms
>
> Are you sure you had CONFIG_DEBUG_LEVEL=0?
Yes, I'm pretty sure. I'm using qemu with -bios bios-fast.bin, and
recompiling SeaBIOS under qemu each time (make && make -C roms bios).
The test program is:
https://github.com/libguestfs/libguestfs/commit/96ce2f9afedc6a7ecb2f7781958c3940255f453b
> Otherwise, it doesn't make
> sense that disabling CONFIG_BOOTORDER=n would change the boot time.
Could it be explained by it avoiding slow access to qemu fw_cfg?
> Disabling CONFIG_DEBUG_SERIAL is not enough, because SeaBIOS also
> writes to port 0x402 as an internal debugging mechanism.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] Why is SeaBIOS used with -kernel?
2016-04-01 19:10 ` Richard W.M. Jones
@ 2016-04-01 19:15 ` Richard W.M. Jones
2016-04-01 19:44 ` Kevin O'Connor
0 siblings, 1 reply; 55+ messages in thread
From: Richard W.M. Jones @ 2016-04-01 19:15 UTC (permalink / raw)
To: Kevin O'Connor
Cc: marc.mari.barcelo, Paolo Bonzini, Stefan Hajnoczi, Gerd Hoffmann,
qemu-devel
On Fri, Apr 01, 2016 at 08:10:48PM +0100, Richard W.M. Jones wrote:
> On Fri, Apr 01, 2016 at 03:04:15PM -0400, Kevin O'Connor wrote:
> > Otherwise, it doesn't make
> > sense that disabling CONFIG_BOOTORDER=n would change the boot time.
>
> Could it be explained by it avoiding slow access to qemu fw_cfg?
Also, disabling CONFIG_BOOTORDER means that CONFIG_BOOT is disabled,
since CONFIG_BOOTMENU and CONFIG_BOOTSPLASH were also disabled, and
those are the only other things requiring CONFIG_BOOT. Could that
explain it?
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] Why is SeaBIOS used with -kernel?
2016-04-01 19:15 ` Richard W.M. Jones
@ 2016-04-01 19:44 ` Kevin O'Connor
2016-04-01 20:25 ` Richard W.M. Jones
0 siblings, 1 reply; 55+ messages in thread
From: Kevin O'Connor @ 2016-04-01 19:44 UTC (permalink / raw)
To: Richard W.M. Jones
Cc: marc.mari.barcelo, Paolo Bonzini, Stefan Hajnoczi, Gerd Hoffmann,
qemu-devel
On Fri, Apr 01, 2016 at 08:15:29PM +0100, Richard W.M. Jones wrote:
> On Fri, Apr 01, 2016 at 08:10:48PM +0100, Richard W.M. Jones wrote:
> > On Fri, Apr 01, 2016 at 03:04:15PM -0400, Kevin O'Connor wrote:
> > > Otherwise, it doesn't make
> > > sense that disabling CONFIG_BOOTORDER=n would change the boot time.
> >
> > Could it be explained by it avoiding slow access to qemu fw_cfg?
No, because fw_cfg isn't slow with DMA. It's just one additional
memory transfer of a file that's under a kilobyte.
> Also, disabling CONFIG_BOOTORDER means that CONFIG_BOOT is disabled,
> since CONFIG_BOOTMENU and CONFIG_BOOTSPLASH were also disabled, and
> those are the only other things requiring CONFIG_BOOT. Could that
> explain it?
Disabling CONFIG_BOOTORDER does not disable CONFIG_BOOT - it only
controls some internal sorting of bootable devices - of which there
are none when CONFIG_DRIVES=n - so I don't see why it would have an
impact.
My understanding of SeaBIOS times is that it is overwhelmingly
dominated by (virtual) hardware accesses. Specifically, when hardware
is touched it causes a VM-exit which takes time. That's why debugging
is slow (and why serial debugging is slow) - it's nothing in SeaBIOS
that causes it to be slow, it's purely the number of IO accesses. The
CONFIG_BOOTORDER option doesn't meaningfully alter the number of IO
accesses, so it's puzzling that it would have an impact on boot time.
Perhaps you could send me the actual seabios .config file of the test
run with and without CONFIG_BOOTORDER. I'll also try to reproduce
locally.
Thanks,
-Kevin
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] Why is SeaBIOS used with -kernel?
2016-04-01 18:41 ` Richard W.M. Jones
2016-04-01 18:59 ` Richard W.M. Jones
@ 2016-04-01 20:05 ` Kevin O'Connor
2016-04-01 20:46 ` Richard W.M. Jones
2016-04-02 5:30 ` Paolo Bonzini
1 sibling, 2 replies; 55+ messages in thread
From: Kevin O'Connor @ 2016-04-01 20:05 UTC (permalink / raw)
To: Richard W.M. Jones
Cc: marc.mari.barcelo, Paolo Bonzini, qemu-devel, Gerd Hoffmann,
Stefan Hajnoczi
On Fri, Apr 01, 2016 at 07:41:31PM +0100, Richard W.M. Jones wrote:
> On Fri, Apr 01, 2016 at 11:35:40AM -0400, Kevin O'Connor wrote:
> > > +# general stuff
> > > +CONFIG_QEMU=y
> > > +CONFIG_ROM_SIZE=128
> >
> > Why force a size of 128K - I would think 64K would be fine.
>
> Agreed. Setting this to =0 seems the best thing, and it does fit fine
> inside 64K.
>
> > > +# no input, no boot menu
> > > +CONFIG_MOUSE=n
> > > +CONFIG_KEYBOARD=n
> > [...]
> > > +CONFIG_DRIVES=n
> >
> > I would not recommended disabling CONFIG_MOUSE, CONFIG_KEYBOARD,
> > CONFIG_DRIVES - I only had those in my config so as to avoid having to
> > specify all the device drivers. Ideally these would remain on and the
> > individual device drivers would be disabled.
>
> We are always use this in a virtual appliance. Interaction with the
> user is both impossible and undesirable. It either boots or not, and
> the whole appliance is discarded in seconds. We're always using
> -kernel with this SeaBIOS build, so probing drives is never needed.
Okay, but if it doesn't change the boot time, then it would be nicer
to use a standard rom for all boots.
I looked closer at your setup and it appears the SeaBIOS virtio-scsi
driver is very slow because it does a full search of all 256 possible
scsi targets. This full scan takes a lot of time. I put together a
quick patch (see below) to stop the scan early. Gerd/Paulo, do you
know if what I've done is valid and/or if there is a better way we can
limit the virtio-scsi scan?
I also found a way to reduce the overhead of the "shadow ram" code a
little. I have a patch (see below) for that as well.
Another consumer of time is ACPI table deployment. I wonder if you
could get similar results by running QEMU with "-no-acpi"?
Beyond that, I think the only other big time consumers of the default
seabios is debug messages. If so, then I think we can come up with a
way to limit these debug messages in SeaBIOS.
The SeaBIOS testing patches are at:
https://github.com/KevinOConnor/seabios/tree/testing
Thanks,
-Kevin
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] Why is SeaBIOS used with -kernel?
2016-04-01 19:44 ` Kevin O'Connor
@ 2016-04-01 20:25 ` Richard W.M. Jones
0 siblings, 0 replies; 55+ messages in thread
From: Richard W.M. Jones @ 2016-04-01 20:25 UTC (permalink / raw)
To: Kevin O'Connor
Cc: marc.mari.barcelo, Paolo Bonzini, Stefan Hajnoczi, Gerd Hoffmann,
qemu-devel
On Fri, Apr 01, 2016 at 03:44:14PM -0400, Kevin O'Connor wrote:
[...]
I ran all the tests again, but this time I ran the test program 3
times (so 30 passes for each setting). As you can see from the
results below the test is not very stable, so that could easily have
accounted for the variation I saw when I only ran the test program
once for each setting.
The difference in .config is just:
--- seabios-bootorder=n.config 2016-04-01 21:19:53.599230008 +0100
+++ seabios-bootorder=y.config 2016-04-01 21:19:31.090441232 +0100
@@ -14,7 +14,7 @@
CONFIG_THREADS=y
# CONFIG_RELOCATE_INIT is not set
# CONFIG_BOOTMENU is not set
-# CONFIG_BOOTORDER is not set
+CONFIG_BOOTORDER=y
CONFIG_ENTRY_EXTRASTACK=y
CONFIG_MALLOC_UPPERMEMORY=y
CONFIG_ROM_SIZE=0
Rich.
----------------------------------------------------------------------
CONFIG_BOOTORDER=y
passes 10
append
backend libvirt
hv /home/rjones/d/qemu/x86_64-softmmu/qemu-system-x86_64
memsize 500
smp 1
Result: 1098.0ms ±0.8ms
passes 10
append
backend libvirt
hv /home/rjones/d/qemu/x86_64-softmmu/qemu-system-x86_64
memsize 500
smp 1
Result: 1095.9ms ±0.4ms
passes 10
append
backend libvirt
hv /home/rjones/d/qemu/x86_64-softmmu/qemu-system-x86_64
memsize 500
smp 1
Result: 1087.5ms ±3.8ms
CONFIG_BOOTORDER=n
passes 10
append
backend libvirt
hv /home/rjones/d/qemu/x86_64-softmmu/qemu-system-x86_64
memsize 500
smp 1
Result: 1103.4ms ±2.6ms
passes 10
append
backend libvirt
hv /home/rjones/d/qemu/x86_64-softmmu/qemu-system-x86_64
memsize 500
smp 1
Result: 1097.2ms ±4.8ms
passes 10
append
backend libvirt
hv /home/rjones/d/qemu/x86_64-softmmu/qemu-system-x86_64
memsize 500
smp 1
Result: 1098.0ms ±8.3ms
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] Why is SeaBIOS used with -kernel?
2016-04-01 20:05 ` Kevin O'Connor
@ 2016-04-01 20:46 ` Richard W.M. Jones
2016-04-01 22:25 ` Kevin O'Connor
2016-04-02 5:30 ` Paolo Bonzini
1 sibling, 1 reply; 55+ messages in thread
From: Richard W.M. Jones @ 2016-04-01 20:46 UTC (permalink / raw)
To: Kevin O'Connor
Cc: marc.mari.barcelo, Paolo Bonzini, qemu-devel, Gerd Hoffmann,
Stefan Hajnoczi
On Fri, Apr 01, 2016 at 04:05:46PM -0400, Kevin O'Connor wrote:
> On Fri, Apr 01, 2016 at 07:41:31PM +0100, Richard W.M. Jones wrote:
> > On Fri, Apr 01, 2016 at 11:35:40AM -0400, Kevin O'Connor wrote:
> > > > +# general stuff
> > > > +CONFIG_QEMU=y
> > > > +CONFIG_ROM_SIZE=128
> > >
> > > Why force a size of 128K - I would think 64K would be fine.
> >
> > Agreed. Setting this to =0 seems the best thing, and it does fit fine
> > inside 64K.
> >
> > > > +# no input, no boot menu
> > > > +CONFIG_MOUSE=n
> > > > +CONFIG_KEYBOARD=n
> > > [...]
> > > > +CONFIG_DRIVES=n
> > >
> > > I would not recommended disabling CONFIG_MOUSE, CONFIG_KEYBOARD,
> > > CONFIG_DRIVES - I only had those in my config so as to avoid having to
> > > specify all the device drivers. Ideally these would remain on and the
> > > individual device drivers would be disabled.
> >
> > We are always use this in a virtual appliance. Interaction with the
> > user is both impossible and undesirable. It either boots or not, and
> > the whole appliance is discarded in seconds. We're always using
> > -kernel with this SeaBIOS build, so probing drives is never needed.
>
> Okay, but if it doesn't change the boot time, then it would be nicer
> to use a standard rom for all boots.
I don't think I know which option (or options) make the boot faster,
but bios-fast.bin is certainly much faster than the qemu standard
bios.bin -- no amount of variability in the test framework would
account for that huge difference of 44ms.
I had convinced myself before that maybe CONFIG_DRIVES=n was the
factor, but that setting alone doesn't actually make much difference:
bios-fast.bin (CONFIG_DRIVES=n):
Result: 1093.3ms ±3.4ms
Result: 1100.6ms ±8.9ms
bios-fast.bin + CONFIG_DRIVES=y:
Result: 1100.3ms ±8.4ms
Result: 1101.7ms ±1.2ms
It could be just one setting or an accumulation of several settings.
At some point I may have the patience to try each one but probably not
late on Friday night :-/
> I looked closer at your setup and it appears the SeaBIOS virtio-scsi
> driver is very slow because it does a full search of all 256 possible
> scsi targets. This full scan takes a lot of time. I put together a
> quick patch (see below) to stop the scan early. Gerd/Paulo, do you
> know if what I've done is valid and/or if there is a better way we can
> limit the virtio-scsi scan?
>
> I also found a way to reduce the overhead of the "shadow ram" code a
> little. I have a patch (see below) for that as well.
I would say the patches on the KevinOConnor/testing branch don't make
any measurable difference.
Stock qemu SeaBIOS:
Result: 1218.6ms ±1.0ms
Result: 1214.1ms ±0.0ms
KevinOConnor/testing branch:
Result: 1221.9ms ±0.5ms
Result: 1216.4ms ±0.2ms
> Another consumer of time is ACPI table deployment. I wonder if you
> could get similar results by running QEMU with "-no-acpi"?
No apparent difference:
Stock qemu SeaBIOS:
Result: 1211.5ms ±4.8ms
Stock qemu SeaBIOS + qemu -no-acpi:
Result: 1213.9ms ±6.5ms
> Beyond that, I think the only other big time consumers of the default
> seabios is debug messages. If so, then I think we can come up with a
> way to limit these debug messages in SeaBIOS.
>
> The SeaBIOS testing patches are at:
>
> https://github.com/KevinOConnor/seabios/tree/testing
Thanks,
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://libguestfs.org
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] Why is SeaBIOS used with -kernel?
2016-04-01 20:46 ` Richard W.M. Jones
@ 2016-04-01 22:25 ` Kevin O'Connor
2016-04-02 7:51 ` Richard W.M. Jones
0 siblings, 1 reply; 55+ messages in thread
From: Kevin O'Connor @ 2016-04-01 22:25 UTC (permalink / raw)
To: Richard W.M. Jones
Cc: marc.mari.barcelo, Paolo Bonzini, qemu-devel, Gerd Hoffmann,
Stefan Hajnoczi
On Fri, Apr 01, 2016 at 09:46:05PM +0100, Richard W.M. Jones wrote:
> On Fri, Apr 01, 2016 at 04:05:46PM -0400, Kevin O'Connor wrote:
> > On Fri, Apr 01, 2016 at 07:41:31PM +0100, Richard W.M. Jones wrote:
> > > On Fri, Apr 01, 2016 at 11:35:40AM -0400, Kevin O'Connor wrote:
> > > > > +# general stuff
> > > > > +CONFIG_QEMU=y
> > > > > +CONFIG_ROM_SIZE=128
> > > >
> > > > Why force a size of 128K - I would think 64K would be fine.
> > >
> > > Agreed. Setting this to =0 seems the best thing, and it does fit fine
> > > inside 64K.
> > >
> > > > > +# no input, no boot menu
> > > > > +CONFIG_MOUSE=n
> > > > > +CONFIG_KEYBOARD=n
> > > > [...]
> > > > > +CONFIG_DRIVES=n
> > > >
> > > > I would not recommended disabling CONFIG_MOUSE, CONFIG_KEYBOARD,
> > > > CONFIG_DRIVES - I only had those in my config so as to avoid having to
> > > > specify all the device drivers. Ideally these would remain on and the
> > > > individual device drivers would be disabled.
> > >
> > > We are always use this in a virtual appliance. Interaction with the
> > > user is both impossible and undesirable. It either boots or not, and
> > > the whole appliance is discarded in seconds. We're always using
> > > -kernel with this SeaBIOS build, so probing drives is never needed.
> >
> > Okay, but if it doesn't change the boot time, then it would be nicer
> > to use a standard rom for all boots.
>
> I don't think I know which option (or options) make the boot faster,
> but bios-fast.bin is certainly much faster than the qemu standard
> bios.bin -- no amount of variability in the test framework would
> account for that huge difference of 44ms.
>
> I had convinced myself before that maybe CONFIG_DRIVES=n was the
> factor, but that setting alone doesn't actually make much difference:
>
> bios-fast.bin (CONFIG_DRIVES=n):
>
> Result: 1093.3ms ±3.4ms
> Result: 1100.6ms ±8.9ms
>
> bios-fast.bin + CONFIG_DRIVES=y:
>
> Result: 1100.3ms ±8.4ms
> Result: 1101.7ms ±1.2ms
>
> It could be just one setting or an accumulation of several settings.
> At some point I may have the patience to try each one but probably not
> late on Friday night :-/
>
> > I looked closer at your setup and it appears the SeaBIOS virtio-scsi
> > driver is very slow because it does a full search of all 256 possible
> > scsi targets. This full scan takes a lot of time. I put together a
> > quick patch (see below) to stop the scan early. Gerd/Paulo, do you
> > know if what I've done is valid and/or if there is a better way we can
> > limit the virtio-scsi scan?
> >
> > I also found a way to reduce the overhead of the "shadow ram" code a
> > little. I have a patch (see below) for that as well.
>
> I would say the patches on the KevinOConnor/testing branch don't make
> any measurable difference.
>
> Stock qemu SeaBIOS:
>
> Result: 1218.6ms ±1.0ms
> Result: 1214.1ms ±0.0ms
>
> KevinOConnor/testing branch:
>
> Result: 1221.9ms ±0.5ms
> Result: 1216.4ms ±0.2ms
I'm getting different results. When you have time we should probably
track down the discrepancy. Some of the difference is likely due to
different hardware (I'm using kvm on an old AMD machine) and some is
likely due to different test methodology (I'm timing SeaBIOS debug
output). However, the changes on that testing branch reliably improve
the boot by 70ms for me when there is a virtio-scsi device present.
Have a good weekend.
-Kevin
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] Why is SeaBIOS used with -kernel?
2016-04-01 20:05 ` Kevin O'Connor
2016-04-01 20:46 ` Richard W.M. Jones
@ 2016-04-02 5:30 ` Paolo Bonzini
1 sibling, 0 replies; 55+ messages in thread
From: Paolo Bonzini @ 2016-04-02 5:30 UTC (permalink / raw)
To: Kevin O'Connor, Richard W.M. Jones
Cc: marc.mari.barcelo, Stefan Hajnoczi, qemu-devel, Gerd Hoffmann
On 01/04/2016 22:05, Kevin O'Connor wrote:
>
> I looked closer at your setup and it appears the SeaBIOS virtio-scsi
> driver is very slow because it does a full search of all 256 possible
> scsi targets. This full scan takes a lot of time. I put together a
> quick patch (see below) to stop the scan early. Gerd/Paulo, do you
> know if what I've done is valid and/or if there is a better way we can
> limit the virtio-scsi scan?
No, it's not possible because target numbers are arbitrary. We can
submit all 256 requests at the same time perhaps.
Paolo
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] Why is SeaBIOS used with -kernel?
2016-04-01 22:25 ` Kevin O'Connor
@ 2016-04-02 7:51 ` Richard W.M. Jones
0 siblings, 0 replies; 55+ messages in thread
From: Richard W.M. Jones @ 2016-04-02 7:51 UTC (permalink / raw)
To: Kevin O'Connor
Cc: marc.mari.barcelo, Paolo Bonzini, qemu-devel, Gerd Hoffmann,
Stefan Hajnoczi
On Fri, Apr 01, 2016 at 06:25:24PM -0400, Kevin O'Connor wrote:
> I'm getting different results. When you have time we should probably
> track down the discrepancy. Some of the difference is likely due to
> different hardware (I'm using kvm on an old AMD machine) and some is
> likely due to different test methodology (I'm timing SeaBIOS debug
> output). However, the changes on that testing branch reliably improve
> the boot by 70ms for me when there is a virtio-scsi device present.
Indeed - I have retested everything in the cold light of day, and
it does save time.
SeaBIOS master branch from current git:
Result: 974.2ms ±2.0ms
Result: 988.5ms ±11.3ms
Result: 974.9ms ±7.3ms
SeaBIOS KevinOConnor/testing branch:
Result: 942.5ms ±4.2ms
Result: 930.0ms ±2.1ms
Result: 934.7ms ±3.4ms
(Note these times are not comparable with the previous ones, because
in a parallel set of investigations I've disabled libvirt and am
running qemu directly, so there is no libvirt overhead.)
Thanks,
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://libguestfs.org
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] Why is SeaBIOS used with -kernel?
2016-04-01 11:20 ` Richard W.M. Jones
2016-04-01 11:21 ` Paolo Bonzini
@ 2016-04-05 4:38 ` Kevin Wolf
2016-04-05 8:04 ` Richard W.M. Jones
1 sibling, 1 reply; 55+ messages in thread
From: Kevin Wolf @ 2016-04-05 4:38 UTC (permalink / raw)
To: Richard W.M. Jones
Cc: marc.mari.barcelo, Stefan Hajnoczi, qemu-devel,
Kevin O'Connor, Gerd Hoffmann, Paolo Bonzini
Am 01.04.2016 um 13:20 hat Richard W.M. Jones geschrieben:
>
> My patch, plus the configuration and comments from your patch,
> combined. Plus I tested it with libguestfs boot-analysis and it works
> and is still fast.
>
> Integrating this so it happens automatically when the user adds
> -kernel on x86 seems quite complicated. The only way I could do it
> was by adding #ifdef defined(__x86_64__) etc to vl.c, which doesn't
> seem very nice. The problem is the machine type code doesn't know
> that you're using -kernel.
I would actually find it rather surprising to get differernt BIOSes and
therefore potentially different behaviour for -kernel and for booting
from an image. Even if we made sure that Linux really never touches the
parts that you disable in bios-fast.bin, remember that -kernel is not
only for Linux, but for arbitrary kernels.
Requiring an explicit -bios option like you do now seems to make most
sense to me: The default behaves the same as a normal boot, but if you
are one of the cases that do need that additional boot speed, you can do
that and consciously sacrifice the features.
Kevin
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] Why is SeaBIOS used with -kernel?
2016-04-05 4:38 ` Kevin Wolf
@ 2016-04-05 8:04 ` Richard W.M. Jones
2016-04-05 8:11 ` Kevin Wolf
0 siblings, 1 reply; 55+ messages in thread
From: Richard W.M. Jones @ 2016-04-05 8:04 UTC (permalink / raw)
To: Kevin Wolf
Cc: marc.mari.barcelo, Stefan Hajnoczi, qemu-devel,
Kevin O'Connor, Gerd Hoffmann, Paolo Bonzini
On Tue, Apr 05, 2016 at 06:38:36AM +0200, Kevin Wolf wrote:
> Am 01.04.2016 um 13:20 hat Richard W.M. Jones geschrieben:
> >
> > My patch, plus the configuration and comments from your patch,
> > combined. Plus I tested it with libguestfs boot-analysis and it works
> > and is still fast.
> >
> > Integrating this so it happens automatically when the user adds
> > -kernel on x86 seems quite complicated. The only way I could do it
> > was by adding #ifdef defined(__x86_64__) etc to vl.c, which doesn't
> > seem very nice. The problem is the machine type code doesn't know
> > that you're using -kernel.
>
> I would actually find it rather surprising to get differernt BIOSes and
> therefore potentially different behaviour for -kernel and for booting
> from an image. Even if we made sure that Linux really never touches the
> parts that you disable in bios-fast.bin, remember that -kernel is not
> only for Linux, but for arbitrary kernels.
>
> Requiring an explicit -bios option like you do now seems to make most
> sense to me: The default behaves the same as a normal boot, but if you
> are one of the cases that do need that additional boot speed, you can do
> that and consciously sacrifice the features.
OK so this reminds me of the second problem. How to detect what
bioses are available, given a qemu binary. It would be nice if qemu
had an option like:
qemu -bios \?
Of course we can try to scan /usr/share/qemu/bios.*, except that
Fedora installs extra ROMs in /usr/share/seabios/ (I'm not exactly
sure how qemu deals with those), and the path is different for other
distros and other qemu binaries.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] Why is SeaBIOS used with -kernel?
2016-04-05 8:04 ` Richard W.M. Jones
@ 2016-04-05 8:11 ` Kevin Wolf
2016-04-05 9:19 ` Richard W.M. Jones
0 siblings, 1 reply; 55+ messages in thread
From: Kevin Wolf @ 2016-04-05 8:11 UTC (permalink / raw)
To: Richard W.M. Jones
Cc: marc.mari.barcelo, Stefan Hajnoczi, qemu-devel,
Kevin O'Connor, Gerd Hoffmann, Paolo Bonzini
Am 05.04.2016 um 10:04 hat Richard W.M. Jones geschrieben:
> On Tue, Apr 05, 2016 at 06:38:36AM +0200, Kevin Wolf wrote:
> > Am 01.04.2016 um 13:20 hat Richard W.M. Jones geschrieben:
> > >
> > > My patch, plus the configuration and comments from your patch,
> > > combined. Plus I tested it with libguestfs boot-analysis and it works
> > > and is still fast.
> > >
> > > Integrating this so it happens automatically when the user adds
> > > -kernel on x86 seems quite complicated. The only way I could do it
> > > was by adding #ifdef defined(__x86_64__) etc to vl.c, which doesn't
> > > seem very nice. The problem is the machine type code doesn't know
> > > that you're using -kernel.
> >
> > I would actually find it rather surprising to get differernt BIOSes and
> > therefore potentially different behaviour for -kernel and for booting
> > from an image. Even if we made sure that Linux really never touches the
> > parts that you disable in bios-fast.bin, remember that -kernel is not
> > only for Linux, but for arbitrary kernels.
> >
> > Requiring an explicit -bios option like you do now seems to make most
> > sense to me: The default behaves the same as a normal boot, but if you
> > are one of the cases that do need that additional boot speed, you can do
> > that and consciously sacrifice the features.
>
> OK so this reminds me of the second problem. How to detect what
> bioses are available, given a qemu binary. It would be nice if qemu
> had an option like:
>
> qemu -bios \?
>
> Of course we can try to scan /usr/share/qemu/bios.*, except that
> Fedora installs extra ROMs in /usr/share/seabios/ (I'm not exactly
> sure how qemu deals with those), and the path is different for other
> distros and other qemu binaries.
At least in RHEL, /usr/share/qemu-kvm/bios.* seems to have symlinks
pointing to the binaries in /usr/share/seabios/. And I would assume that
that's the only directory besides the working directory where qemu looks
for the files.
Kevin
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] Why is SeaBIOS used with -kernel?
2016-04-05 8:11 ` Kevin Wolf
@ 2016-04-05 9:19 ` Richard W.M. Jones
2016-04-05 9:26 ` Kevin Wolf
0 siblings, 1 reply; 55+ messages in thread
From: Richard W.M. Jones @ 2016-04-05 9:19 UTC (permalink / raw)
To: Kevin Wolf
Cc: marc.mari.barcelo, Stefan Hajnoczi, qemu-devel,
Kevin O'Connor, Gerd Hoffmann, Paolo Bonzini
> > OK so this reminds me of the second problem. How to detect what
> > bioses are available, given a qemu binary. It would be nice if qemu
> > had an option like:
> >
> > qemu -bios \?
I didn't really think this one through. The extra time taken (in the
link loader) to run the above query command will be greater than the
time saved with the faster BIOS. I'm still looking at the loader
problem.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [Qemu-devel] Why is SeaBIOS used with -kernel?
2016-04-05 9:19 ` Richard W.M. Jones
@ 2016-04-05 9:26 ` Kevin Wolf
0 siblings, 0 replies; 55+ messages in thread
From: Kevin Wolf @ 2016-04-05 9:26 UTC (permalink / raw)
To: Richard W.M. Jones
Cc: marc.mari.barcelo, Stefan Hajnoczi, qemu-devel,
Kevin O'Connor, Gerd Hoffmann, Paolo Bonzini
Am 05.04.2016 um 11:19 hat Richard W.M. Jones geschrieben:
> > > OK so this reminds me of the second problem. How to detect what
> > > bioses are available, given a qemu binary. It would be nice if qemu
> > > had an option like:
> > >
> > > qemu -bios \?
>
> I didn't really think this one through. The extra time taken (in the
> link loader) to run the above query command will be greater than the
> time saved with the faster BIOS. I'm still looking at the loader
> problem.
For all practical matters, why can't you make it a build time option?
The binary would hardcode bios-fast.bin and just set the dependencies of
the libguestfs package to a new enough qemu.
Kevin
^ permalink raw reply [flat|nested] 55+ messages in thread
end of thread, other threads:[~2016-04-05 9:27 UTC | newest]
Thread overview: 55+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-03-19 20:31 [Qemu-devel] Why is SeaBIOS used with -kernel? Richard W.M. Jones
2016-03-21 7:58 ` Gerd Hoffmann
2016-03-21 8:37 ` Richard W.M. Jones
2016-03-21 9:40 ` Gerd Hoffmann
2016-03-31 9:21 ` Stefan Hajnoczi
2016-03-31 16:22 ` Kevin O'Connor
[not found] ` <20160331221039.GA32728@redhat.com>
2016-03-31 22:17 ` Richard W.M. Jones
2016-03-31 22:44 ` Kevin O'Connor
2016-04-01 7:55 ` Richard W.M. Jones
2016-04-01 8:03 ` Paolo Bonzini
2016-04-01 8:47 ` Richard W.M. Jones
2016-04-01 8:51 ` Paolo Bonzini
2016-04-01 8:57 ` Richard W.M. Jones
2016-04-01 9:05 ` Paolo Bonzini
2016-04-01 8:02 ` Richard W.M. Jones
2016-04-01 8:11 ` Paolo Bonzini
2016-04-01 8:14 ` Richard W.M. Jones
2016-04-01 8:24 ` Paolo Bonzini
2016-04-01 8:44 ` Richard W.M. Jones
2016-04-01 8:47 ` Paolo Bonzini
2016-04-01 8:49 ` Vasiliy Tolstov
2016-04-01 9:16 ` Dr. David Alan Gilbert
2016-04-01 9:18 ` Gerd Hoffmann
2016-04-01 10:17 ` Richard W.M. Jones
2016-04-01 11:07 ` Gerd Hoffmann
2016-04-01 11:11 ` Richard W.M. Jones
2016-04-01 11:20 ` Richard W.M. Jones
2016-04-01 11:21 ` Paolo Bonzini
2016-04-01 11:26 ` Richard W.M. Jones
2016-04-05 4:38 ` Kevin Wolf
2016-04-05 8:04 ` Richard W.M. Jones
2016-04-05 8:11 ` Kevin Wolf
2016-04-05 9:19 ` Richard W.M. Jones
2016-04-05 9:26 ` Kevin Wolf
2016-04-01 11:32 ` Gerd Hoffmann
2016-04-01 11:49 ` Richard W.M. Jones
2016-04-01 15:35 ` Kevin O'Connor
2016-04-01 16:03 ` Paolo Bonzini
2016-04-01 18:41 ` Richard W.M. Jones
2016-04-01 18:59 ` Richard W.M. Jones
2016-04-01 19:04 ` Kevin O'Connor
2016-04-01 19:10 ` Richard W.M. Jones
2016-04-01 19:15 ` Richard W.M. Jones
2016-04-01 19:44 ` Kevin O'Connor
2016-04-01 20:25 ` Richard W.M. Jones
2016-04-01 20:05 ` Kevin O'Connor
2016-04-01 20:46 ` Richard W.M. Jones
2016-04-01 22:25 ` Kevin O'Connor
2016-04-02 7:51 ` Richard W.M. Jones
2016-04-02 5:30 ` Paolo Bonzini
2016-04-01 15:08 ` Kevin O'Connor
2016-04-01 14:58 ` Kevin O'Connor
2016-04-01 15:06 ` Richard W.M. Jones
2016-04-01 15:14 ` Kevin O'Connor
2016-04-01 8:19 ` Richard W.M. Jones
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.