On 22.03.2012 09:31, David Cure wrote:
Le Wed, Mar 21, 2012 at 06:31:02PM +0100, Peter Lieven ecrivait :
please keep in mind, that setting -hypervisor, disabling hpet and only
one vcpu
makes windows use tsc as clocksource. you have to make sure, that your vm
is not switching between physical sockets on your system and that you have
constant_tsc feature to have a stable tsc between the cores in the
same socket. its also likely that the vm will crash when live migrated.
ok, yet I "only" have disable hpet and use 1vcpu.
you have to use 1 vcpu on 32-bit windows. 64-bit seems to
work with more than 1 vcpu. why all those limitations:
windows avoids using tsc in a hypervisor which is a good decision.
problem is it falls back to pm_timer or hpet. both of them are very
expensive in emulation currently because kvm exits kernel mode
and the userspace qemu-kvm handles this. i have done experiments
where i saw ~20.000 userpace exits just for pmtimer reads. this
made up ~30-40% of the whole processing power. every call to a
QPC timer in windows causes a pm_timer/hpet read. especially
each i/o request seems to cause a QPC timer read and which
is odd as well a lazy fpu call (but this is a differnt issue) which also
is very expensive to emulate (currently).
for the switching I need to pin the vcpu on 1 physical proc,
right ?
you need 1 vcpu for 32-bit windows and disabling hypervisor to
cheat windows and make it think it runs on real hardware. it then
uses tsc.
for constant_tsc, how can I check if I use it ?
cat /proc/cpuinfo on the host. there should be a flag 'constant_tsc'.
it might be that also rdtscp is necessary.
for live migration : what is the "feature" that cause trouble :
-hypervisor, hpet, vcpu or all ?
using tsc as clocksource is the problem not the features themselves.
peter
David.
--
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
