Muli Ben-Yehuda
Mon, 10 Jul 2006 03:54:46 -0700
On Mon, Jul 10, 2006 at 12:04:37PM +0300, Shachar Shemesh wrote: > There are two parts to this equation (para vs. fully virtualized host). > One is the use of some impossible to easily virtualize CPU commands on > normal pentium CPUs. The two workarounds are: > 1. Tell the virtualized machine not to use them (para-virtualize) Actually, para-virtualization refers to one specific way of telling the virtualized machine to not use them via source code modifications. There's also the afterburner approach (modify the toolchain) and the VMware approach (rewrite the instruction stream at run-time). > Actually, there is a third workaround, but I'm not sure what it is. This > is what VMWare uses (at least in VMWare ESX, the hypervisor does that in > order to run Windows on non-VT machines). There's a very good book about this whose name escapes me at the moment, as well as several papers that explain how to do dynamic rewriting. Ping me if you want references. > I highly doubt that there is any significant performance problem between > the first two solutions. I can imagine that the third solution does have > some performance degradation. You have to quantify what you mean (as I did in my original mail). The *CPU* performance is roughly the same with the first two solutions. The *IO* performance is reasonable with the first, and awful with the second as it is currently implemented in Xen. This is not inherent in the methods themselves, but rather has to do with how they are used. The first method is used for a PV Linux, where the IO drivers are PV as well. The second is used for a FV Windows (or Linux, doesn't matter), where the native drivers are used and the hardware is *emulated* in dom0. > Then there is the IO issue. Again, there are two possible solutions: > 1. Emulate the DMA, IO and interrupt behavior of a real SCSI/IDE device, > and let the guest machine use the standard drivers. > 2. Let the guest machine communicate directly with the host machine, > using the direct IO performance. Again, there are many different ways of achieveing each of these, but I agree to the broad taxonomy. > Option 2 is, obviously, much better, performance wise. I know very smart people who think the first option can be just as efficient as the first, given a few constraints. Personally, I'm reserving judgement until I see the numbers. > VMWare, for example, does #1 intelligently. It can emulate both an IDE > and a SCSI controller, and according to the guest OS you wish to install > it will recommend the IDE controller if there are no easy drivers for > the SCSI (say, if you install DOS or Windows 95), and the SCSI > controller otherwise (if you install Windows XP or Linux 2.6). This > allows it to provide better performance already. Emulation is inherently limited in what it can achieve. You can however play with the placement of the emulated devices and with the emulation itself to tune the perofrmance. > It will also do #2, however. After the guest operating system is > installed, it will recommend you install "VMWare Tools". This will > install various drivers on the guest machine that communicate directly > with the host, bypassing many of the performance bottlenecks. While it's > true that this allows such strange things as having the guest OS change > resolution every time you resize the host window (my current Windows > 2000 resolution is 1016x631), having the mouse move fluently in and out > of the guest window or being able to copy/paste between machines, what > it REALLY allows is for low overhead IO. > > My current SCSI driver on Windows 2000 is called "VMWare SCSI Controller". > > Yes, I think that it's possible, with XEN, to write a Windows driver for > performing direct IO, and performance should not suffer once someone > does. How does this contradict my statement that at the moment, IO performance with FV guests on Xen sucks? many people are working on improving it via a variety of methods. Patches happily accepted :-) (and as for VMware - I haven't seen an IO benchmarks from them. I have seen a EULA clauses that disallows benchmarks. Drawing conclusions left as an exercise to the reader). Cheers, Muli ================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]