On Oct 7, 2008, at 17:15 , Andrew Lyon wrote:
On Tue, Oct 7, 2008 at 3:31 PM, Pim van Riezen <pi
+lists@xxxxxxxxxxxx> wrote:
On Oct 7, 2008, at 16:20 , Andrew Lyon wrote:
I've briefly tried xen/xend 3.2 on the machine. If I used the
/boot/xen.gz-3.2 as the hypervisor, /proc/cpuinfo would stop
listing vmx
among the capabilities. Going back to the RedHat version of
xen-3.1 and
xend-3.0, I get them back:
Not that it helps with your problem, but not seeing vmx in
/proc/cpuinfo is normal for newer versions of Xen, after all Linux
cannot use the vmx feature as it is already being used by the Xen
hypervisor, so it is logical that the feature is no longer listed.
At least it's good to know there is nothing inherently wrong with
that
xen-3.2 hypervisor then, although the end result on that hypervisor
was the
same (cpu of the guest got fully emulated, slower than booting GEOS
on my
C64).
Pi
I don't think that is possible, afaik Xen can only run Windows through
HVM, there was a modified build of windows that was paravirtualized
but it was never released to the public, only some Xen developers at
cambridge university had access, so you are using vmx/hvm and your
problem is not that the cpu is being fully emulated, it is something
else!
Ok, in that case let me restate my question without preconceptions
about its cause:
I start the guest, it starts eating 100% cpu in xm top. It takes
forever booting and logging me into a desktop. It's the effect of
running on a severely underpowered CPU of a 386 class or lower. In
xentop, Domain-0 also seems to be taking up a lot of cpu, around 70%.
Running top in Dom0 shows qemu-md taking up that cpu-time.
If qemu-md were running a bochs-style emulation, that is what I'd
expect to see.
If I start the same guest on the Xeon 5150 machine, I see 0% CPU usage
in Domain-0 and the guest boots like lightning.
Cheers,
Pi
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home