Le Wednesday 28 Aug 2013 à 15:14:41 (+0200), Paolo Bonzini a écrit : > Il 28/08/2013 11:07, Erik Rull ha scritto: > >>> It could be a real difference, actually. An unexpectedly fast disk > >>> might screw a sloppy driver. IIRC you're not the first person reporting > >>> it. Stefan, do you think using block throttling could fix it (with some > >>> trial and error)? > >> > >> That might work. You could start with something like -drive ...,iops=20 > >> and then disable the limit from the QEMU monitor once the guest OS is > >> booting (block_set_io_throttle virtio0 0 0 0 0 0 0). > >> > >> It would be easier to try -drive ...,cache=writethrough and -win2k-hack > >> first as Anthony suggests. > >> > >> Stefan > > > > Thanks. > > I tried that, but when should I reset the throttle? > > Never. The bug will be there through the whole execution of the guest. > > > When I reset it some seconds > > after the BIOS screen disappeared same result as without throttling. When I > > keep > > it, Windows still reboots, the cycle just takes longer (half an hour), but > > the > > progress seems to be the same as without throttle. > > On second thought that is expected. Until throttling kicks in, I/O will > complete just as fast as without throttling. Maybe limiting the number > of bytes per second instead of I/O ops would be better. Can you try > -drive ...,bps=1048576 (possibly higher or lower numbers too)? > > And maybe Benoit's new algorithm could help too. Benoit, do you have a > tree for Erik to try?
Hi Eric, You can find my latest throttling work on the leaky_continuous_final2 branch of the following git tree. git clone g...@gitorious.org:benoit-canet-qemu/benoit-canet-qemu.git git checkout leaky_continuous_final2 Hope this help Best regards Benoît