| |
|
 |
|
 |
|
|
|
| |
|
|
xen-users
RE: [Xen-users] Intel VT platform vs SVM (Pacifica)
> -----Original Message-----
> From: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
> [mailto:xen-users-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of
> Matt Ouellette
> Sent: 25 July 2006 17:55
> To: xen-users@xxxxxxxxxxxxxxxxxxx
> Subject: [Xen-users] Intel VT platform vs SVM (Pacifica)
>
>
> We're looking to buy a new servers. We're planning on using Xen to
> consolidate our many boxes into one. Which platform would be the best
> for this?
>
> I've searched for documentation supporting either side, but have found
> none. I have heavily researched the Performance and specs of the
> processors and platforms. From what I gather Intel is
> probably going to
> be my first choice.
I'd like to know why you don't choose AMD... ;-)
>
> What are issues that you guys have run into using Xen on
> either an Intel
> or AMD with hardware supported virtualization. Has anyone found
> documents clearly stating which is superior?
> I am also interested in people's personal experience with
> platforms with
> hardware virtualization enabled.
One current problem with VT is the fact that it doesn't support
real-mode in virtualized mode - they have to suse tricks in VM86 mode,
which is not nice... AMD processors can run in "Paged Real-mode" in VM86
mode. However, be balanced, real-mode is almost certainly only needed
for booting the system, so it's not a BIG deal. There's work to use QEMU
for the entire real-mode boot process on VT, since that will allow
emulating the parts where it's getting into troubel right now [graphical
boot in SuSE for example - the boot-loader uses "clever tricks" to load
data into memory above 1MB, and that's failing in the current VT
implementation].
I would think that anything stating that one is clearly superior to the
other would be hard to find for a few reasons:
1. The implementation, although done by two differnet companies, are
pretty identical [clue might be in the fact that they both closely
looked at the VM technology by IBM that just ran out of patent...].
Since the way that the virtualization works is pretty much identical,
one can presume that the results of any benchmarking effort would be
pretty close too.
2. The AMD processors haven't been on the market for that long...
3. The by far most time-consuming part of any fully virtualized guest is
time spent in emulated devices. For example, a disk-read would incur 5-6
vmexits to write the commands to the IDE controller, then a further
interrupt-injection back to the guest to indicate that the data is
availble, and finally another vmexit for the read of the data (unless
the driver is braindead and does 256 or 512 read operations). Each one
of these vmexits cause a full context switch from the guest to the Dom0
application of qemu-dm, and back again. The amount of time spent here is
much bigger than any difference between AMD and Intel's implementations
will show - if it takes 500 cycles to do a vmexit on AMD and 550 on
Intel, you will not notice when it takes 10000 cycles to performe the
rest of the operations, right? [I have a vague idea of how many cycles
AMD and Intel take to do a VMEXIT, and no idea whatsoever what the
cycles needed for a full context switch, but the order of magnitude of
those numbers are probably not completely wrong].
>
> Does Debian Sarge support Xen with VT or SVM?
Xen 3.0.2 supports both VT and SVM - I wouldn't recommend running
anything much older than that, because there's been a few problems with
running HVM in the earlier releases.
I hope this helps...
--
Mats
>
> so many question so little time. Thanks.
>
>
> _______________________________________________
> 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