| |
|
 |
|
 |
|
|
|
| |
|
|
xen-users
RE: [Xen-users] XEN emulation situations
> -----Original Message-----
> From: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
> [mailto:xen-users-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of
> Alexander Kostadinov
> Sent: 21 June 2006 09:46
> To: xen-users@xxxxxxxxxxxxxxxxxxx
> Subject: [Xen-users] XEN emulation situations
>
> Hallo. I want to use xen on a EM64T dual-core machine without
> HT and with
> the intel's VT technology.
> First of all I want to be sure that xen uses the VT technology and
> Second: Is xen running DomU in a slow emulation mode for any
> reason on
> such a machine?
Xen 3.x will use Intel VT/AMD SVM technology for HVM guest (unmodified
guests), but no VT/SVM technology is being used for modified guests.
>
> I ask that because I cannot manage to see the bootup xen log (dmesg
> doesn't show it) and I cannot find the answer for the second question
> anywhere. I can't find anywhere verified that using the VT solves the
> problems with TLS and others.
Have you tried "xm dmesg"? That should give you the Xen bootup
messages...
The TLS "problem" with Xen is really a small issue - there's very little
performance gained from negative segment offsets (which is what TLS
uses), so using other techniques to solve the same problem are now being
introduced into the distributions - but old distros obviously still come
with TLS libraries (at least that's how I read previous posts on this
subject).
But yes, VT solves this - at least to the extent that TLS libraries can
be used in the guest without problem. Dom0 still has to run without
TLS...
However, other things are slower on VT, so you'd have to have a
particularly special case for this to actually gain you something. All
hardware accesses go through QEMU-DM, which is a significant overhead
compared to accessing them through the para-virtualized interface of a
Xenified Linux.
The purpose of the ability to run unmodified guests, at the moment, is
really to support situations where modifying the OS to "understand Xen"
isn't feasible for one reason or another, e.g. running Windows (no
source code easily available), validated kernels (some product is
supported for SuSE 9.3 with the supplied compiled kernel - and running
something else voids the support contract that you have for the product)
or perhaps running old kernels (there's currently no support for 2.4
kernels in Xen 3.x - so you'd have to run it as a unmodified guest if
you can't convince you/the boss that a 2.6 kernel will work just as
well).
With future enhancements, things will most likely improve
performance-wise, and at some point it should be possible to assign real
hardware directly to the guest, which eliminates the emulated devices
for this mode of operation.
I hope this helps.
--
Mats
>
> Thank you in advance.
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-users
>
>
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
|
|
| |
|
Home