* [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
[parent not found: <20160331221039.GA32728@redhat.com>]
* 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-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: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 ` 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-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 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: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: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: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: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
* 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 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 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 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 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 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 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 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 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 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 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
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.