On Tue, Aug 03, 2010 at 01:10:00PM +0100, Richard W.M. Jones wrote: > On Tue, Aug 03, 2010 at 02:33:02PM +0300, Gleb Natapov wrote: > > On Tue, Aug 03, 2010 at 12:13:06PM +0100, Richard W.M. Jones wrote: > > > > > > qemu compiled from today's git. Using the following command line: > > > > > > $qemudir/x86_64-softmmu/qemu-system-x86_64 -L $qemudir/pc-bios \ > > > -drive file=/dev/null,if=virtio \ > > > -enable-kvm \ > > > -nodefaults \ > > > -nographic \ > > > -serial stdio \ > > > -m 500 \ > > > -no-reboot \ > > > -no-hpet \ > > > -net user,vlan=0,net=169.254.0.0/16 \ > > > -net nic,model=ne2k_pci,vlan=0 \ > > > -kernel /tmp/libguestfsEyAMut/kernel \ > > > -initrd /tmp/libguestfsEyAMut/initrd \ > > > -append 'panic=1 console=ttyS0 udevtimeout=300 noapic acpi=off printk.time=1 cgroup_disable=memory selinux=0 guestfs_vmchannel=tcp:169.254.2.2:35007 guestfs_verbose=1 TERM=xterm-color ' > > > > > > With kernel 2.6.35 [*], this takes about 1 min 20 s before the guest > > > starts. > > > > > > If I revert back to kernel 2.6.34, it's pretty quick as usual. > > > > > > strace is not very informative. It's in a loop doing select and > > > reading/writing from some file descriptors, including the signalfd and > > > two pipe fds. > > > > > > Anyone seen anything like this? > > > > > I assume your initrd is huge. > > It's ~110MB, yes. > > > In newer kernels ins/outs are much slower that they were. They are > > much more correct too. It shouldn't be 1 min 20 sec for 100M initrd > > though, but it can take 20-30 sec. This belongs to kvm list BTW. > > I can't see anything about this in the kernel changelog. Can you > point me to the commit or the key phrase to look for? > 7972995b0c346de76 > Also, what's the point of making in/out "more correct" when they we > know we're talking to qemu (eg. from the CPUID) and we know it already > worked fine before with qemu? > Qemu has nothing to do with that. ins/outs didn't worked correctly for some situation. They didn't work at all if destination/source memory was MMIO (didn't work as in hang vcpu IIRC and this is security risk). Direction flag wasn't handled at all (if it was set instruction injected #GP into a gust). It didn't check that memory it writes to is shadowed in which case special action should be taken. It didn't delivered events during long string operations. May be more. Unfortunately adding all that makes emulation much slower. I already implemented some speedups, and more is possible, but we will not be able to get to previous string io speed which was our upper limit. -- Gleb. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
