WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-users

RE: [Xen-users] AMD SVN and Xen3

Ok, second try - so a bit shorter :)

Hi Mats. Thanks for reply.

To your questions:

> Exactly which version of Xen are you running (copy of the output from
> "xm info" would help!).

I found out a few hours after writing the message that I am running 3.0.2
instead of 3.0.2-2. I guess that was the reason for many of the bugs :/
Running 3.0.2-2 now because I have to keep the system going. So switching
to an unstable/testing version isn't that easy as long as one of the more
recent versions of Xen are intended to work clean (only with some minor
quirks)

>> So all in all no luck. But there is a question: Does AMD64's SVM
>> (Pacifica) work also when being in 32-Bit-mode?

I can answer that myself: Yep. Running AMD SVM in 32-bit-mode. :)

>
> We test both 32- and 64-bit versions of Xen when we make our
> contributions to Xen-source, so it _SHOULD_ work. Of course, sometimes
> we'll miss something in one direction or the other [I mostly develop on
> a 64-bit base, so I personally know that my changes work on 64-bit
> systems, but before it's submitted to Xen-Source, all changes should be
> tested on 32-bit systems too], there's certainly no INTENTIONAL
> differences. But since 64-bit version of Xen was a bit flaky early on,
> the first version of Xen to work on SVM was the 32-bit version - so
> since I saw that you got the 32-bit version working, perhaps you're
> running an older version of Xen...

As stated I did :/ I am running Debian ETCH with 3.0.2-2 now. As far as I
can see, no trouble with paravirtualized OSes. Only remaining problems
with hvm ones. Named: System crash when running more than one hvm domain.
Not exactly to locate when, but randomly the complete (host)machine does
die (no output of course). Installing Win2k3 crashes once while setup (can
be reproduced) and then sets up/works fine (after restarting setup -
without SP1). When installing SP1 it reboots as soon as you log in
(actually it takes a few seconds to load some stuff - no access to the
desktop). I guess its the SP1 installer that makes the hvm crash.

>
> Also, not so long ago, SMP-version of the Hypervisor would cause all
> sorts of problems, but it's been fixed for several weeks at least... Xen
> changes very much from day to day...

Thats where my next question goes to: "Testing" - does it make sense
trying it on a production system for the sake of having a windows-hvm
running? Or is there a 3.0.2-3 or 3.0.3 near the horizon (thats worth
waiting for (reason again: stability)) ?

Another big question is: Will there be support for the integrated network
controller of current nVidia-powered boards? (Because the one Xen is using
is far outdated. I wonder because I can't believe that the vanilla-kernel
lacks that driver... (its included in the debian kernel for example)

When posting here, maybe I can ask another question:
Did you change the scheduler? Several things to notice: 2.0.7: A domain
could _never_ completely block the other running domains. When doing heavy
work in 3.0.2-2 in dom0 it basically pauses the domUs completely. 99%
CPU-load for Dom0 and nothing for DomU. Maybe you don't notice that much
on current Systems, but a small Celeron700-system became completely
unresponsible when compiling a new kernel (for example). No Network (ssh),
prompt after login for console (xm console vmX) took approx. 5 minutes. I
never noticed that before. I am also wondering because the speed of the
domUs is terribly slow. I don't expect a P4 here, but the domU ran on a
physical Celeron 433 before - and was double as fast.
Another noticed thing (on an other machine) is: is it "normal", that a
hvm-domain that boots up normally on CPU1 (pinned) consumes 30-70%
CPU0-Load on the both-CPU-located dom0? (AMD X2 4600) This seems to be a
pretty big ammount for a single domain... (196MB Ram for the domain, no
graphical output) Basically the cpu load of the dom0 was higher than the
load of the domU.

Just wanted to get rid of these ones :) Maybe some could be answered -
maybe some will stay a mystery till eternety... :D

However, great work and thanks for the extensive willing to help :)

Regards, Bigfoot29



_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users

<Prev in Thread] Current Thread [Next in Thread>