Great information, and straight from the source! Can you tell me on
which version of KVM support for TPR was implemented? I assume I am not up
to said version, but I want to confirm, because when I start my Windows
guests (currently all uniprocessor) in KVM, csrss.exe uses all available
processor constantly until I follow the KVM Windows ACPI workaround
directions. I have updated since December, but I am running Fedora 7 rpms,
so I may have to move up a version or two to get that support. Thanks,
Dustin
-----Original Message-----
From: Avi Kivity [mailto:avi@qumranet.com]
Sent: Tuesday, May 20, 2008 11:55
To: Dustin.Henning(a)prd-inc.com
Cc: fedora-xen(a)redhat.com
Subject: Re: [Fedora-xen] HVM DomU on F9?
Dustin Henning wrote:
I actually prefer to run HVM DomUs in a regular kernel if
possible
because I have always had mouse problems in Dom0 of F7, but not in the
base
kernel. I understand that KVM is an option, but since Xen now
supports
Windows with ACPI (without the degradation that was once common in Xen and
is still common in KVM because of a certain ACPI register apparently
regularly polled by Windows [I would love to know what register, as I
could
It's called that Task Priority Register, or TPR.
> then try to find a way to prevent Windows from doing that and KVM might
> perform as well as Xen]), I feel that KVM would be a big step backwards.
For uniprocessor guests, kvm supports TPR optimization (since December
2007). It's disabled on SMP guests due to stability issues, unfortunately.
Additionally, there are apparently more paravirtual drivers available
for
Windows (though they are not readily available in binary form and stable,
more on that in my next message), though using std-vga in KVM is nice
(with
standard VESA 2.0, a generic Windows driver already exists outside of
the
project).
A paravirtualized network driver is freely available for kvm. It is
still not fully stable under heavy loads, though. We expect to fix this
soon.
--
error compiling committee.c: too many arguments to function