> > sudo perf record -a -F $((250*100)) -e cycles:u -- > > /usr/bin/qemu-system-x86_64 -name guest="guest" .... > > I instead attached perf to the qemu process after it was spawned by > libvirt so I didn't have to worry about producing a working qemu > cmdline. I let it run for several seconds while still in the paused > state.
Sure! > > And check where we're spending so much time for the boot to happen. > > Note I'm using "cycles:u", getting only userland stack trace probes > > every (HZ*100),. > > This showed no samples - apparently all samples were kernel side. Either kernel or VMX/SVM mode. > > That might give us enough information. > > > > Would you mind opening a launchpad bug (can be private if you prefer) > > so Christian and I can take a look ? > > Sure: > https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1838575 Err, sorry to ask you this, but I'm getting magic/endian check errors on perf report, maybe something related to the arch and perf. Would you mind reporting to stdio and pasting into the case ? Are you using fully updated Eoan (userland/kernel) for everything ? (c)inaddy@temp:~/temp$ sudo /usr/lib/linux-tools/5.2.0-8-generic/perf report -f -v magic/endian check failed Tks! -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1838575 Title: passthrough devices cause >17min boot delay To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1838575/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
