Singapore Citizen Mr. Teo En Ming (Zhang Enming)

Announcing the Release of the World’s First 64-bit Build of Google’s ChromiumOS for Netbooks

2009-11-30T06:43:00.000+08:00

I have ported the development code of the open source ChromiumOS project to 64-bit. Google Chrome OS will be officially released in late 2010, and it will be based on the Chromium OS project.

My 64-bit build of ChromiumOS is called ChromiumOS64. Download your copy now!

Download link: http://www.chromiumos64.org/

Video of Google Chrome OS (ChromiumOS) in Action on VMware Workstation and Sun VirtualBox as a Virtual Machine

2009-11-25T02:06:00.001+08:00

http://www.youtube.com/watch?v=nSkszmeFcYg

Latest Google Chrome OS (ChromiumOS) VMware VMDK Image File Download: Guaranteed to Work!

2009-11-24T19:22:00.002+08:00

Google Chrome OS (ChromiumOS) is a 32-bit Linux netbook operating system based on Ubuntu 9.10 Karmic Koala i386 (Development Branch).

Filename: Google-Chrome-OS-build-enming.teo-24Nov2009-0528.vmdk.bz2

Filesize: 280 MB

Type: VMware VMDK image file bzipped

md5sum: 23371970c3b1c5dee287b9bb97901b7d

sha1sum: 4f12627f58e34bb2d29b99627ce043bc6c30aaac

sha256sum: 9853bfb6220882660caebddd0395c03adfb122563918fbfc16e7070ad3a9e14c

sha384sum: 46b1c0321cee250117fbd9fad16a3d5eb341a8a68d3ac51e80cb1f32d8c1be7b4fa057c470f8250922d939928314a454

Download Link #1: http://www.zshare.net/download/689075349802a081/

Download Link #2: http://www.filefactory.com/file/a1d69he/n/Google-Chrome-OS-build-enming.teo-24Nov2009-0528.vmdk.bz2

Download Link #3: http://www.mediafire.com/?jme4zmydzzb

How to Use:

1. Decompress with bzip2 on Linux.

$ bzip2 -d Google-Chrome-OS-build-enming.teo-24Nov2009-0528.vmdk.bz2

2. Use as virtual harddisk with the open source Xen hypervisor, Sun VirtualBox, VMware Workstation, or VMware Player

3. To convert the VMDK image file to Xen HVM domU image file for use with Xen, follow the instructions at the following link.

http://wiki.xensource.com/xenwiki/VMDKImage

Google Chrome OS Download

2009-11-22T18:23:00.001+08:00

Filename: Google-Chrome-OS-Build-enming.teo-22Nov2009-0704hrs.vmdk

Filesize: 697.38MB

Type: VMware VMDK image file

MD5 checksum: 1aec57157dd2083b166e493c0e831a67

Download link: http://www.zshare.net/download/68819648ff817281/

Video of Google Chrome OS (Chromium OS) on Xen

2009-11-22T16:50:00.003+08:00

http://www.youtube.com/watch?v=Icl59WmC56I

Picture Tutorial: How to DIY your own Google Chrome OS with Xen-based Ubuntu 9.10 Karmic Koala amd64 Virtual Machine in Fedora 11 x86_64 Pv-Ops Dom0

2009-11-22T16:41:00.001+08:00

Video Demo: Building a Rocks HPC Cluster with Xen Hardware Virtual Machines (HVM) (Update 1)

2009-11-09T23:54:00.001+08:00

This is the new video demo of my Rocks HPC compute cluster after I have set dom0_mem=1024M for my Xen hypervisor.

I started all 5 nodes at one go without crashing and without sluggishness.

Previous video demo shows that I can only start 3 nodes with-out setting dom0_mem for the Xen hypervisor. If I attempt to start the 4th node, dom0 will freeze.

This is proof that setting dom0_mem really works and improves overall system performance.

Link: http://www.youtube.com/watch?v=vWHIImVBr4o

Video Demo: Building a Rocks HPC Cluster with Xen Hardware Virtual Machines (HVM)

2009-11-09T19:04:00.002+08:00

http://www.youtube.com/watch?v=LbLaPpwNAx4

Video Tutorial: How to Setup a Virtual Supercomputer Center or HPC Cluster using Xen Virtual Machines

2009-10-31T20:09:00.002+08:00

Video #1 of 2:

http://www.youtube.com/watch?v=GmNKi6CoExM

Video #2 of 2:

http://www.youtube.com/watch?v=dAqDESEWMjM

Reference [1]: http://lists.mcs.anl.gov/pipermail/mpich-discuss/2009-October/005883.html

Reference [2]: http://lists.xensource.com/archives/html/xen-devel/2009-10/msg01440.html

Using Xen Virtualization Environment for Development and Testing of Supercomputing and High Performance Computing (HPC) Cluster MPICH2 Applications

2009-10-30T18:25:00.006+08:00

Screenshots:

Read my thread at the mpich-discuss mailing list: http://lists.mcs.anl.gov/pipermail/mpich-discuss/2009-October/005883.html

Read my thread at the xen-devel mailing list: http://lists.xensource.com/archives/html/xen-devel/2009-10/msg01440.html

Xen Virtualization: 2nd Iteration of the Super PI 32M Benchmark Test

2009-10-28T02:25:00.001+08:00

http://www.youtube.com/watch?v=m7W0OFFcw7I

This is after setting tsc_native=1 in my Windows XP HVM configuration.

Xen Virtualization, VT-d, VGA Passthrough, & Windows XP HVM Virtual Machine: Super PI 32M Benchmark

2009-10-28T00:04:00.002+08:00

http://www.youtube.com/watch?v=3mxuNRiMxDU

My Intel Pentium Dual Core E6300 @ 2.8 GHz outperforms AMD Phenom II X2 550 BE clocked at 3.6 GHz.

http://forums.hardwarezone.com.sg/showthread.php?t=2527603&page=12

Xen Virtualization & Intel VT-d: Direct Hardware Access to Graphics Card by Windows HVM Virtual Machines

2009-10-27T14:37:00.005+08:00

http://www.youtube.com/watch?v=HHUwg_zxYgw

This video shows Xen 3.5-unstable (changeset 20143), VT-d, pv-ops dom0 kernel 2.6.31.4, VGA passthrough, HD audio passthrough, and Windows XP HVM guest operating system in action.

Host Operating System Domain 0: Fedora 11 Linux x86-64 64-bit
Domain U: Windows XP Home Edition SP3 32-bit HVM Virtual Machine
Xen Hypervisor Version: 3.5-unstable changeset 20143
Paravirt-Operations Dom0 Kernel: 2.6.31.4 (Jeremy Fitzhardinge's git tree)
Intel GFX Passthrough Patches Applied: Version 1 (Provided by Han Weidong Intel)

Motherboard: Intel DQ45CB
BIOS Version: 0093
Processor: Intel Pentium Dual Core E6300
Graphics Card: nVidia GeForce 8400 GS PCI Express x16
Memory: 8GB DDR2-800

Version of Xen GPL PV (GPLPV) Drivers Installed: 07/15/2009 0.10.0.86

Full implementation details are here: http://lists.xensource.com/archives/html/xen-devel/2009-10/msg01134.html

VGA and HD audio passthrough are fully working. Although device manager reports that it is working, OHCI IEEE1394 firewire controller passthrough is not working as expected. Video cameras with firewire attached to the firewire port cannot be detected.

USB optical mouse and USB keyboard have also been successfully passed through to Windows XP HVM guest.

Xen PV-OPS Dom0 Kernel 2.6.31.4 Testing

2009-10-24T12:49:00.004+08:00

For more information, read here: http://lists.xensource.com/archives/html/xen-devel/2009-10/msg01134.html

IEEE 1394a Firewire Controller Passthrough Work in Progress

2009-10-21T22:22:00.001+08:00

http://lists.xensource.com/archives/html/xen-devel/2009-10/msg00607.html

pvops dom0 kernel 2.6.31.1 Build Successful

2009-10-21T22:14:00.001+08:00

http://lists.xensource.com/archives/html/xen-devel/2009-10/msg00374.html

Xen Virtualization: Playing 3D Accelerated FPS Games in Windows XP Virtual Machine

2009-10-21T21:36:00.005+08:00

http://www.youtube.com/watch?v=5tLzYqIJ7Q0

Technical discussions:

July 2009: http://lists.xensource.com/archives/html/xen-devel/2009-07/index.html

August 2009: http://lists.xensource.com/archives/html/xen-devel/2009-08/index.html

September 2009: http://lists.xensource.com/archives/html/xen-devel/2009-09/index.html

October 2009: http://lists.xensource.com/archives/html/xen-devel/2009-10/index.html

USB Device Pass Through Succeeded

2009-09-14T02:09:00.002+08:00

How thick I must have been! In my earlier blog posts with VGA passthrough succeeded, I said that I couldn't passthrough any USB device at all.

As a matter of fact, Timothy had corrected my usbdevice directive in the guest config file in an earlier mailing list post but I didn't take a careful look at the usbdevice directive at all. The correct usbdevice directive is:

usbdevice = "host:vendorid:productid"

I had used

usbdevice = [ 'host:vendorid:productid' ]

which is completely erroneous. I need to omit the square brackets for USB device passthrough to work.

I have now successfully passed through the USB optical mouse to the Windows XP Home HVM domU and using on-screen keyboard as a substitute for the physical USB keyboard.

The reason I am doing this is because QEMU with Xen can only allow one USB device to be passed through at any one time.

It was so obvious and I missed the obvious!

PVOPS Dom 0 kernel 2.6.31 and Mainline Kernel 2.6.31

2009-09-14T02:02:00.002+08:00

I couldn't get Jeremy's rebase/master branch (pvops dom 0 kernel 2.6.31) to work despite disabling all of USB support in the kernel. I will troubleshoot this issue with the serial console enabled another time.

Meanwhile, I got Linus' mainline kernel 2.6.31 to work on my system. So apparently the dom 0 patched kernel 2.6.31 has some issues or I did not configure it properly.

Disabled all USB support in the kernel...

2009-09-13T08:27:00.001+08:00

but I still couldn't get pvops dom0-patched kernel 2.6.31 final to complete loading. All I get is a blinking cursor at the top left hand corner of the monitor.

UHCI, OHCI, EHCI, and xHCI disabled...

2009-09-12T20:15:00.001+08:00

but I still could not get pvops dom 0 kernel 2.6.31 final to complete loading.

Disabling USB 1.0, USB 2.0 Drivers and Enabling USB 3.0 Drivers

2009-09-12T18:05:00.002+08:00

I have disabled USB 1.0 and USB 2.0 drivers simultaneously and enabled USB 3.0 driver but the kernel stops loading.

Then I totally disabled all USB support by passing the "nousb" parameter to the kernel but it still stops loading.

After disabling the USB 1.0 Host Controller Driver...

2009-09-12T16:34:00.004+08:00

but still leaving the USB 2.0 Host Controller Driver compiled statically into the kernel, I get an error with the USB 2.0 driver.

Obviously this is a USB driver problem with the pvops dom 0 kernel 2.6.31 final or an incompatibility issue with the USB controller on the Intel DQ45CB motherboard. I have no issues with USB on pvops dom 0 kernels 2.6.30-rc3 and 2.6.31-rc6, and also regular kernels.

If I keep disabling the USB drivers any further, I will not be able to use USB keyboard and mouse on my system. My Intel DQ45CB motherboard does not have any PS/2 ports. But I may still be able to serial console in.

Error with pv-ops dom 0 kernel 2.6.31 final

2009-09-12T10:46:00.002+08:00

Below is a screenshot of the error I have encountered with this kernel.

USB Host Controller died?! Above screenshot shows USB 1.0 driver having problems.

Disk I/O Benchmark Results with Xen-based Windows XP Home HVM Virtual Machine

2009-09-11T23:20:00.004+08:00

Common Configuration: Xen 3.5-unstable with Intel supplied VGA passthrough patches
VGA passthrough status: nVidia GeForce 8400 GS PCI Express x16 graphics card fully passed through

Case #1: Jeremy's Fitzhardinge's pvops dom 0 kernel 2.6.30-rc3

Case #2: Jeremy Fitzhardinge's pvops dom 0 kernel 2.6.31-rc6

Observation: The above benchmark results show that Windows XP Home Edition 32-bit HVM guest operating system runs faster in 2.6.30-rc3 than 2.6.31-rc6. All services which could have affected the performance of Win XP domU have been stopped in Dom 0.

The Final Solution: PCI Express x16 Graphics Card Passthrough to Windows XP Home Edition 32-bit HVM Virtual Machine

2009-09-10T20:48:00.019+08:00

Here is my latest video presentation on VGA passthrough. Please check out the Youtube link at

http://www.youtube.com/watch?v=1ia3IwG6tp4

The "not enough free resources" issue for nVidia Geforce 8400 GS PCI Express x16 graphics card in earlier presentation videos:

http://www.youtube.com/watch?v=HNEiSInrav0

http://www.youtube.com/watch?v=_hOT_9LIG5w

has been fixed. Device manager in Windows XP HVM domU no longer shows an exclamation mark besides the nVidia Geforce 8400 GS graphics card. The device is working properly and the resources tab shows the available memory ranges.

Full VGA passthrough to Windows XP HVM guest operating system using Xen virtualization has been achieved. I am now able to run 3-D video benchmarks on the passed through nVidia GeForce 8400 GS graphics card.

All this is possible using Xen 3.5 hypervisor with Intel supplied VGA passthrough patches. Instead of using pvops dom0 kernel 2.6.31-rc6 which causes Win XP domU to run slowly, I am now using pvops dom0 kernel 2.6.30-rc3.

I am now able to bootstrap Windows XP HVM domU from within Linux using Xen virtualization and play 3D games in the Windows virtual machine. In the past, Windows virtual machines can only access a 2D emulated/virtual display adapter. The virtualized Windows operating systems were more palatable to server administrators than gamers. With VGA pass through and direct hardware access by Windows virtual machines to the graphics hardware, gamers will now be able to play 3D games inside Windows virtual machines.

There is still one unresolved problem. I am still unable to passthrough USB devices, e.g. keyboard and mouse, to the Windows XP HVM domU.

Special thanks to the following people who have helped me along the way. Without their guidance I would not have made it this far.

(1) Boris Derzhavets
(2) Pasi Kärkkäinen
(3) Han Weidong, Intel Corporation
(4) Doug Magee
(5) Timothy Moore
(6) Christian Tramnitz

and many other people from the xen-devel mailing list.

References:

[1] Direct Access to Graphics Card Leveraging VT-d Technical Report; Beng Heng Ng, Billy Lau and Atul Prakash; July 20, 2009; University of Michigan

URL: http://www.eecs.umich.edu/~bengheng/pubs/vgapt_techreport.pdf

[2] VGA passthrough in Xen; Y. Schaeffer; University of Amsterdam

URL: http://staff.science.uva.nl/~delaat/sne-2008-2009/p22/presentation.pdf

[3] Xen VGA passthrough; Yuri Schaeer BSc; University of Amsterdam

URL: http://staff.science.uva.nl/~delaat/sne-2008-2009/p22/report.pdf

Video Presentation on PCI Express x16 VGA Passthrough to Xen-based Windows XP Home HVM Virtual Machine

2009-09-07T05:41:00.006+08:00

I have made and uploaded a two-part video series on VGA pass through to Windows XP HVM domU to Youtube.

Here are the Youtube links:

http://www.youtube.com/watch?v=HNEiSInrav0

http://www.youtube.com/watch?v=_hOT_9LIG5w

Basically Windows XP guest operating system has direct access to PCI Express x16 graphics card but in a reduced functionality state. The videos show that the passed through display card cannot found enough resources it can use. The device status for nVidia Geforce 8400 GS on my Intel Desktop Board DQ45CB is:

This device cannot find enough free resources that it can use. (Code 12)

I could not run any 3-D video benchmark tests at the moment. I have tried Sisoftware Sandra Lite 2009.SP4 and Passmark Performance Test benchmark suites. 3-D video benchmark tests in both suites cannot be started at all. Work on direct graphics card access by Windows virtual machines is still in progress but this paves the way for heavy 3-D gaming in Windows virtual machines in the future. Besides processors, graphics card virtualization will become mainstream in the not-too-distant future. The technology requires Intel Virtualization Technology for Directed Input/Output (VT-d).

In addition to graphics card, you also need to pass through the USB keyboard and USB optical mouse to the Windows virtual machine in order to use it. However, USB pass through is currently not possible on Xen 3.5-unstable with Intel applied VGA passthrough patches. The code is still experimental and under constant development.

Special thanks to Xen virtualization developers and engineers at Intel Corporation for making VGA passthrough possible.

Thank you very much.

Windows XP Home DomU Test Results after applying Intel's VGA Passthrough Patchset to Xen 3.5-unstable

2009-08-29T21:31:00.005+08:00

Dear All,

I have applied the following patches to xen 3.5-unstable

1) intel-gfx-passthru-patch01.patch
2) intel-gfx-passthru-patch02.patch
3) intel-gfx-passthru-patch03.patch
4) enming-patch04.patch

and compiled xen 3.5-unstable successfully (both hypervisor and tools).

i rebooted into this newly compiled Xen hypervisor which supports loading vga bios from firmware file of nVidia Geforce 8400 GS PCI Express x16.

After dom0 has booted up, I executed the following script to hide nVidia Geforce 8400 GS from dom0.

[enming@fedora11-x86-64-host scripts]$ cat bind-devices-pci-stub.sh
#!/bin/sh
echo "10de 06e4" > /sys/bus/pci/drivers/pci-stub/new_id
echo "0000:01:00.0" > /sys/bus/pci/devices/0000:01:00.0/driver/unbind
echo "0000:01:00.0" > /sys/bus/pci/drivers/pci-stub/bind

I also assigned the nVidia Geforce 8400 GS to my Windows XP Home HVM domU.

pci = [ '01:00.0' ]

I also specified gfx_passthru=2.

Do note that I booted up with onboard Intel GMA4500 as the primary video adapter. Hence dom 0 has onboard graphics and Windows XP HVM domU has nvidia graphics.

Then I started Windows XP Home HVM DomU.

Very soon, my Dom 0's display was garbaged and X server on Dom 0 totally froze and became unresponsive. I cannot switch to any ttys.

However, I was still able to vnc into my Windows XP Home HVM Dom U. I had earlier installed a VNC server into my Windows XP guest. After remoting in to my Windows XP DomU through vnc, I found that NVIDIA Geforce 8400 GS cannot be initialized and no resources are available for this graphics card.

It shows that the emulated virtual VGA card is now disabled (not appearing in Windows XP Home DomU's device manager) and only the nVidia Geforce 8400 GS VGA BIOS gets loaded.

Intel's VGA Passthrough Patchset to xen 3.5-unstable
====================================================

1) intel-gfx-passthru-patch01.patch

diff -r 5d7e7a250267 tools/firmware/hvmloader/config.h
--- a/tools/firmware/hvmloader/config.h Wed Aug 26 18:28:44 2009 +0800
+++ b/tools/firmware/hvmloader/config.h Thu Aug 27 16:54:24 2009 +0800
@@ -15,7 +15,7 @@
#define PCI_ISA_IRQ_MASK 0x0c20U /* ISA IRQs 5,10,11 are PCI connected */

/* MMIO hole: Hardcoded defaults, which can be dynamically expanded. */
-#define PCI_MEM_START 0xf0000000
+#define PCI_MEM_START 0xe0000000
#define PCI_MEM_END 0xfc000000
extern unsigned long pci_mem_start, pci_mem_end;

diff -r 5d7e7a250267 tools/firmware/hvmloader/hvmloader.c
--- a/tools/firmware/hvmloader/hvmloader.c Wed Aug 26 18:28:44 2009 +0800
+++ b/tools/firmware/hvmloader/hvmloader.c Fri Aug 28 14:41:22 2009 +0800
@@ -113,7 +113,7 @@ unsigned long pci_mem_start = PCI_MEM_ST
unsigned long pci_mem_start = PCI_MEM_START;
unsigned long pci_mem_end = PCI_MEM_END;

-static enum { VGA_none, VGA_std, VGA_cirrus } virtual_vga = VGA_none;
+static enum { VGA_none, VGA_std, VGA_cirrus, VGA_pt } virtual_vga = VGA_none;

static void init_hypercalls(void)
{
@@ -212,8 +212,10 @@ static void pci_setup(void)
case 0x0300:
if ( (vendor_id == 0x1234) && (device_id == 0x1111) )
virtual_vga = VGA_std;
- if ( (vendor_id == 0x1013) && (device_id == 0xb8) )
+ else if ( (vendor_id == 0x1013) && (device_id == 0xb8) )
virtual_vga = VGA_cirrus;
+ else
+ virtual_vga = VGA_pt;
break;
case 0x0680:
/* PIIX4 ACPI PM. Special device with special PCI config space. */
@@ -684,6 +686,11 @@ int main(void)
memcpy((void *)VGABIOS_PHYSICAL_ADDRESS,
vgabios_stdvga, sizeof(vgabios_stdvga));
vgabios_sz = round_option_rom(sizeof(vgabios_stdvga));
+ break;
+ case VGA_pt:
+ printf("Loading VGABIOS of passthroughed gfx ...\n");
+ vgabios_sz =
+ round_option_rom((*(uint8_t *)(VGABIOS_PHYSICAL_ADDRESS+2)) * 512);
break;
default:
printf("No emulated VGA adaptor ...\n");
diff -r 5d7e7a250267 tools/libxc/ia64/xc_ia64_hvm_build.c
--- a/tools/libxc/ia64/xc_ia64_hvm_build.c Wed Aug 26 18:28:44 2009 +0800
+++ b/tools/libxc/ia64/xc_ia64_hvm_build.c Thu Aug 27 16:54:24 2009 +0800
@@ -1109,7 +1109,9 @@ int xc_hvm_build_target_mem(int xc_handl
uint32_t domid,
int memsize,
int target,
- const char *image_name)
+ const char *image_name,
+ int gfx_passthru)
+
{
/* XXX:PoD isn't supported yet */
return xc_hvm_build(xc_handle, domid, target, image_name);
diff -r 5d7e7a250267 tools/libxc/xc_hvm_build.c
--- a/tools/libxc/xc_hvm_build.c Wed Aug 26 18:28:44 2009 +0800
+++ b/tools/libxc/xc_hvm_build.c Thu Aug 27 16:54:24 2009 +0800
@@ -64,6 +64,67 @@ static void build_hvm_info(void *hvm_inf
for ( i = 0, sum = 0; i < hvm_info->length; i++ )
sum += ((uint8_t *)hvm_info)[i];
hvm_info->checksum = -sum;
+}
+
+static int init_vgabios(int xc_handle, uint32_t dom,
+ unsigned char *buffer, uint32_t bios_size)
+{
+ char *va_bios = NULL;
+ uint32_t va_size = 0;
+
+ va_size = bios_size + bios_size % XC_PAGE_SIZE;
+ va_bios = xc_map_foreign_range(xc_handle, dom, va_size,
+ PROT_READ | PROT_WRITE, 0xC0);
+ if ( !va_bios )
+ {
+ IPRINTF("Unable to map vga bios!\n");
+ return -1;
+ }
+
+ if ( buffer != NULL )
+ memcpy(va_bios, buffer, bios_size);
+ else
+ memset(va_bios, 0, bios_size);
+
+ munmap(va_bios, va_size);
+ return 0;
+}
+
+static int setup_vga_pt(int xc_handle, uint32_t dom)
+{
+ int rc = 0;
+ unsigned char *bios = NULL;
+ int bios_size = 0;
+ char *c = NULL;
+ char checksum = 0;
+
+ /* Allocated 64K for the vga bios */
+ if (!(bios = malloc(64 * 1024)))
+ return -1;
+
+#ifdef __linux__
+ bios_size = xc_get_vgabios(bios, 64 * 1024);
+#else
+ bios_size = 0;
+#endif /* __linux__ */
+
+ if (bios_size == 0)
+ {
+ IPRINTF("vga bios size is 0!\n");
+ rc = -1;
+ goto error;
+ }
+
+ /* Adjust the bios checksum */
+ for ( c = (char*)bios; c < ((char*)bios + bios_size); c++ )
+ checksum += *c;
+ if (checksum)
+ bios[bios_size - 1] -= checksum;
+
+ init_vgabios(xc_handle, dom, bios, bios_size);
+error:
+ free(bios);
+ return rc;
}

static int loadelfimage(
@@ -381,7 +442,8 @@ int xc_hvm_build_target_mem(int xc_handl
uint32_t domid,
int memsize,
int target,
- const char *image_name)
+ const char *image_name,
+ int gfx_passthru)
{
char *image;
int sts;
@@ -392,6 +454,11 @@ int xc_hvm_build_target_mem(int xc_handl
return -1;

sts = xc_hvm_build_internal(xc_handle, domid, memsize, target, image, image_size);
+
+ if ( gfx_passthru )
+ sts |= setup_vga_pt(xc_handle, domid);
+ else
+ sts |= init_vgabios(xc_handle, domid, NULL, 0x800);

free(image);

diff -r 5d7e7a250267 tools/libxc/xc_linux.c
--- a/tools/libxc/xc_linux.c Wed Aug 26 18:28:44 2009 +0800
+++ b/tools/libxc/xc_linux.c Thu Aug 27 16:54:24 2009 +0800
@@ -638,6 +638,56 @@ err:
return gnt;
}

+int xc_get_vgabios(unsigned char *buf,
+ int len)
+{
+ int mem;
+ uint32_t start, size = 0;
+ uint16_t magic = 0;
+
+ start = 0xC0000;
+ if (len < size)
+ return 0;
+ if ((mem = open("/dev/mem", O_RDONLY)) < 0)
+ return 0;
+
+ /*
+ ** Check if it a real bios extension.
+ ** The magic number is 0xAA55.
+ */
+ if (start != lseek(mem, start, SEEK_SET))
+ goto out;
+ if (read(mem, &magic, 2) != 2)
+ goto out;
+ if (magic != 0xAA55)
+ goto out;
+ /* Find the size of the rom extension */
+ if (start != lseek(mem, start, SEEK_SET))
+ goto out;
+ if (lseek(mem, 2, SEEK_CUR) != (start + 2))
+ goto out;
+ if (read(mem, &size, 1) != 1)
+ goto out;
+ /* This size is in 512K */
+ size *= 512;
+
+ /*
+ ** Set the file to the begining of the rombios,
+ ** to start the copy.
+ */
+ if (start != lseek(mem, start, SEEK_SET))
+ {
+ size = 0;
+ goto out;
+ }
+ if (size != read(mem, buf, size))
+ size = 0;
+
+out:
+ close(mem);
+ return size;
+}
+
/*
* Local variables:
* mode: C
diff -r 5d7e7a250267 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h Wed Aug 26 18:28:44 2009 +0800
+++ b/tools/libxc/xenctrl.h Thu Aug 27 16:54:24 2009 +0800
@@ -1285,4 +1285,6 @@ int xc_tmem_restore(int xc_handle, int d
int xc_tmem_restore(int xc_handle, int dom, int fd);
int xc_tmem_restore_extra(int xc_handle, int dom, int fd);

+int xc_get_vgabios(unsigned char *bios, int len);
+
#endif /* XENCTRL_H */
diff -r 5d7e7a250267 tools/libxc/xenguest.h
--- a/tools/libxc/xenguest.h Wed Aug 26 18:28:44 2009 +0800
+++ b/tools/libxc/xenguest.h Thu Aug 27 16:54:24 2009 +0800
@@ -135,7 +135,8 @@ int xc_hvm_build_target_mem(int xc_handl
uint32_t domid,
int memsize,
int target,
- const char *image_name);
+ const char *image_name,
+ int gfx_passthru);

int xc_hvm_build_mem(int xc_handle,
uint32_t domid,
diff -r 5d7e7a250267 tools/python/xen/lowlevel/xc/xc.c
--- a/tools/python/xen/lowlevel/xc/xc.c Wed Aug 26 18:28:44 2009 +0800
+++ b/tools/python/xen/lowlevel/xc/xc.c Thu Aug 27 16:54:24 2009 +0800
@@ -894,21 +894,21 @@ static PyObject *pyxc_hvm_build(XcObject
int i;
#endif
char *image;
- int memsize, target=-1, vcpus = 1, acpi = 0, apic = 1;
+ int memsize, target=-1, vcpus = 1, acpi = 0, apic = 1, gfx_passthru = 0;

static char *kwd_list[] = { "domid",
"memsize", "image", "target", "vcpus", "acpi",
- "apic", NULL };
- if ( !PyArg_ParseTupleAndKeywords(args, kwds, "iis|iiii", kwd_list,
+ "apic", "gfx_passthru", NULL };
+ if ( !PyArg_ParseTupleAndKeywords(args, kwds, "iis|iiiii", kwd_list,
&dom, &memsize, &image, &target, &vcpus,
- &acpi, &apic) )
+ &acpi, &apic, &gfx_passthru) )
return NULL;

if ( target == -1 )
target = memsize;

if ( xc_hvm_build_target_mem(self->xc_handle, dom, memsize,
- target, image) != 0 )
+ target, image, gfx_passthru) != 0 )
return pyxc_error_to_exception();

#if !defined(__ia64__)
diff -r 5d7e7a250267 tools/python/xen/xend/XendConfig.py
--- a/tools/python/xen/xend/XendConfig.py Wed Aug 26 18:28:44 2009 +0800
+++ b/tools/python/xen/xend/XendConfig.py Thu Aug 27 16:54:24 2009 +0800
@@ -175,6 +175,7 @@ XENAPI_PLATFORM_CFG_TYPES = {
'pci_msitranslate': int,
'pci_power_mgmt': int,
'xen_platform_pci': int,
+ "gfx_passthru": int,
}

# Xen API console 'other_config' keys.
diff -r 5d7e7a250267 tools/python/xen/xend/image.py
--- a/tools/python/xen/xend/image.py Wed Aug 26 18:28:44 2009 +0800
+++ b/tools/python/xen/xend/image.py Thu Aug 27 16:54:24 2009 +0800
@@ -786,7 +786,7 @@ class HVMImageHandler(ImageHandler):
self.apic = int(vmConfig['platform'].get('apic', 0))
self.acpi = int(vmConfig['platform'].get('acpi', 0))
self.guest_os_type = vmConfig['platform'].get('guest_os_type')
-
+ self.gfx_passthru = int(vmConfig['platform'].get('gfx_passthru', 0))

# Return a list of cmd line args to the device models based on the
# xm config file
@@ -807,7 +807,7 @@ class HVMImageHandler(ImageHandler):

dmargs = [ 'boot', 'fda', 'fdb', 'soundhw',
'localtime', 'serial', 'stdvga', 'isa',
- 'acpi', 'usb', 'usbdevice' ]
+ 'acpi', 'usb', 'usbdevice', 'gfx_passthru' ]

for a in dmargs:
v = vmConfig['platform'].get(a)
@@ -901,6 +901,7 @@ class HVMImageHandler(ImageHandler):
log.debug("vcpus = %d", self.vm.getVCpuCount())
log.debug("acpi = %d", self.acpi)
log.debug("apic = %d", self.apic)
+ log.debug("gfx_passthru = %d", self.gfx_passthru)

rc = xc.hvm_build(domid = self.vm.getDomid(),
image = self.loader,
@@ -908,7 +909,8 @@ class HVMImageHandler(ImageHandler):
target = mem_mb,
vcpus = self.vm.getVCpuCount(),
acpi = self.acpi,
- apic = self.apic)
+ apic = self.apic,
+ gfx_passthru = self.gfx_passthru)
rc['notes'] = { 'SUSPEND_CANCEL': 1 }

rc['store_mfn'] = xc.hvm_get_param(self.vm.getDomid(),
diff -r 5d7e7a250267 tools/python/xen/xm/create.py
--- a/tools/python/xen/xm/create.py Wed Aug 26 18:28:44 2009 +0800
+++ b/tools/python/xen/xm/create.py Thu Aug 27 16:54:24 2009 +0800
@@ -546,6 +546,10 @@ gopts.var('sdl', val='',
gopts.var('sdl', val='',
fn=set_value, default=None,
use="""Should the device model use SDL?""")
+
+gopts.var('gfx_passthru', val='',
+ fn=set_value, default=None,
+ use="""Passthrough graphics card?""")

gopts.var('opengl', val='',
fn=set_value, default=None,
@@ -957,7 +961,8 @@ def configure_hvm(config_image, vals):
'acpi', 'apic', 'usb', 'usbdevice', 'keymap', 'pci', 'hpet',
'guest_os_type', 'hap', 'opengl', 'cpuid', 'cpuid_check',
'viridian', 'xen_extended_power_mgmt', 'pci_msitranslate',
- 'vpt_align', 'pci_power_mgmt', 'xen_platform_pci' ]
+ 'vpt_align', 'pci_power_mgmt', 'xen_platform_pci',
+ 'gfx_passthru' ]

for a in args:
if a in vals.__dict__ and vals.__dict__[a] is not None:

2) intel-gfx-passthru-patch02.patch

From fb818f1060e57dac6793187a70a79801a7c17e50 Mon Sep 17 00:00:00 2001
From: Weidong Han
Date: Thu, 27 Aug 2009 16:51:01 +0800
Subject: [PATCH] qemu gfx passthrough support

support basic gfx passthrough:
- disable emulated VGA adpater if there is passthroughed gfx
- register/unregister legacy VGA I/O ports and MMIOs for passthroughed gfx

Signed-off-by: Ben Lin
Signed-off-by: Weidong Han
---
hw/pass-through.c | 63 +++++++++++++++++++++++++++++++++++++++++++++++++++++
hw/pass-through.h | 6 +++++
hw/pc.c | 51 ++++++++++++++++++++++++------------------
vl.c | 32 +++++++++++++++++++++++---
4 files changed, 126 insertions(+), 26 deletions(-)

diff --git a/hw/pass-through.c b/hw/pass-through.c
index 8d80755..4a9e03a 100644
--- a/hw/pass-through.c
+++ b/hw/pass-through.c
@@ -93,6 +93,8 @@
#include
#include

+extern int gfx_passthru;
+
struct php_dev {
struct pt_dev *pt_dev;
uint8_t valid;
@@ -1781,12 +1783,57 @@ static int pt_dev_is_virtfn(struct pci_dev *dev)
return rc;
}

+/*
+ * register VGA resources for the domain with assigned gfx
+ */
+static int register_vga_regions(struct pt_dev *real_device)
+{
+ int ret = 0;
+
+ ret |= xc_domain_ioport_mapping(xc_handle, domid, 0x3B0,
+ 0x3B0, 0xC, DPCI_ADD_MAPPING);
+
+ ret |= xc_domain_ioport_mapping(xc_handle, domid, 0x3C0,
+ 0x3C0, 0x20, DPCI_ADD_MAPPING);
+
+ ret |= xc_domain_memory_mapping(xc_handle, domid,
+ 0xa0000 >> XC_PAGE_SHIFT,
+ 0xa0000 >> XC_PAGE_SHIFT,
+ 0x20,
+ DPCI_ADD_MAPPING);
+
+ return ret;
+}
+
+/*
+ * unregister VGA resources for the domain with assigned gfx
+ */
+static int unregister_vga_regions(struct pt_dev *real_device)
+{
+ int ret = 0;
+
+ ret |= xc_domain_ioport_mapping(xc_handle, domid, 0x3B0,
+ 0x3B0, 0xC, DPCI_REMOVE_MAPPING);
+
+ ret |= xc_domain_ioport_mapping(xc_handle, domid, 0x3C0,
+ 0x3C0, 0x20, DPCI_REMOVE_MAPPING);
+
+ ret |= xc_domain_memory_mapping(xc_handle, domid,
+ 0xa0000 >> XC_PAGE_SHIFT,
+ 0xa0000 >> XC_PAGE_SHIFT,
+ 0x20,
+ DPCI_REMOVE_MAPPING);
+
+ return ret;
+}
+
static int pt_register_regions(struct pt_dev *assigned_device)
{
int i = 0;
uint32_t bar_data = 0;
struct pci_dev *pci_dev = assigned_device->pci_dev;
PCIDevice *d = &assigned_device->dev;
+ int ret;

/* Register PIO/MMIO BARs */
for ( i = 0; i < PCI_BAR_ENTRIES; i++ )
@@ -1842,6 +1889,16 @@ static int pt_register_regions(struct pt_dev *assigned_device)
(uint32_t)(pci_dev->rom_size), (uint32_t)(pci_dev->rom_base_addr));
}

+ if ( gfx_passthru && (pci_dev->device_class == 0x0300) )
+ {
+ ret = register_vga_regions(assigned_device);
+ if ( ret != 0 )
+ {
+ PT_LOG("VGA region mapping failed\n");
+ return ret;
+ }
+ }
+
return 0;
}

@@ -1891,6 +1948,12 @@ static void pt_unregister_regions(struct pt_dev *assigned_device)

}

+ if ( gfx_passthru && (assigned_device->pci_dev->device_class == 0x0300) )
+ {
+ ret = unregister_vga_regions(assigned_device);
+ if ( ret != 0 )
+ PT_LOG("VGA region unmapping failed\n");
+ }
}

static uint8_t find_cap_offset(struct pci_dev *pci_dev, uint8_t cap)
diff --git a/hw/pass-through.h b/hw/pass-through.h
index 028a03e..956e228 100644
--- a/hw/pass-through.h
+++ b/hw/pass-through.h
@@ -142,6 +142,12 @@ enum {
GRP_TYPE_EMU, /* emul reg group */
};

+enum {
+ GFX_NO_PASSTHRU = 0, /* No gfx pass-through */
+ GFX_IGD_PASSTHRU, /* IGD pass-through */
+ GFX_DISCRETE_PASSTHRU, /* Discrete gfx pass-through */
+};
+
#define PT_GET_EMUL_SIZE(flag, r_size) do { \
if (flag == PT_BAR_FLAG_MEM) {\
r_size = (((r_size) + XC_PAGE_SIZE - 1) & ~(XC_PAGE_SIZE - 1)); \
diff --git a/hw/pc.c b/hw/pc.c
index 129e9d9..53b59c0 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -41,6 +41,7 @@
#include "virtio-balloon.h"
#include "virtio-console.h"
#include "hpet_emul.h"
+#include "pass-through.h"

/* output Bochs bios info messages */
//#define DEBUG_BIOS
@@ -65,6 +66,8 @@ void tpm_tis_init(SetIRQFunc *set_irq, void *opaque, int irq);
extern uint8_t *acpi_tables;
extern size_t acpi_tables_len;

+extern int gfx_passthru;
+
static fdctrl_t *floppy_controller;
static RTCState *rtc_state;
static PITState *pit;
@@ -983,30 +986,34 @@ vga_bios_error:

register_ioport_write(0xf0, 1, 1, ioportF0_write, NULL);

- if (cirrus_vga_enabled) {
- if (pci_enabled) {
- pci_cirrus_vga_init(pci_bus,
- phys_ram_base + vga_ram_addr,
- vga_ram_addr, vga_ram_size);
- } else {
- isa_cirrus_vga_init(phys_ram_base + vga_ram_addr,
- vga_ram_addr, vga_ram_size);
- }
+ if (gfx_passthru == GFX_NO_PASSTHRU) {
+ if (cirrus_vga_enabled) {
+ fprintf(logfile,"cirrus_vga_enabled\n");
+ if (pci_enabled) {
+ pci_cirrus_vga_init(pci_bus,
+ phys_ram_base + vga_ram_addr,
+ vga_ram_addr, vga_ram_size);
+ } else {
+ isa_cirrus_vga_init(phys_ram_base + vga_ram_addr,
+ vga_ram_addr, vga_ram_size);
+ }
#ifndef CONFIG_DM
- } else if (vmsvga_enabled) {
- if (pci_enabled)
- pci_vmsvga_init(pci_bus, phys_ram_base + vga_ram_addr,
- vga_ram_addr, vga_ram_size);
- else
- fprintf(stderr, "%s: vmware_vga: no PCI bus\n", __FUNCTION__);
+ } else if (vmsvga_enabled) {
+ if (pci_enabled)
+ pci_vmsvga_init(pci_bus, phys_ram_base + vga_ram_addr,
+ vga_ram_addr, vga_ram_size);
+ else
+ fprintf(stderr, "%s: vmware_vga: no PCI bus\n", __FUNCTION__);
#endif
- } else if (std_vga_enabled) {
- if (pci_enabled) {
- pci_vga_init(pci_bus, phys_ram_base + vga_ram_addr,
- vga_ram_addr, vga_ram_size, 0, 0);
- } else {
- isa_vga_init(phys_ram_base + vga_ram_addr,
- vga_ram_addr, vga_ram_size);
+ } else if (std_vga_enabled) {
+ fprintf(logfile,"std_vga_enabled\n");
+ if (pci_enabled) {
+ pci_vga_init(pci_bus, phys_ram_base + vga_ram_addr,
+ vga_ram_addr, vga_ram_size, 0, 0);
+ } else {
+ isa_vga_init(phys_ram_base + vga_ram_addr,
+ vga_ram_addr, vga_ram_size);
+ }
}
}

diff --git a/vl.c b/vl.c
index 62bed05..72f3479 100644
--- a/vl.c
+++ b/vl.c
@@ -48,6 +48,7 @@
#include

#include "qemu-xen.h"
+#include "hw/pass-through.h"

#include
#include
@@ -213,6 +214,7 @@ static int rtc_date_offset = -1; /* -1 means no change */
int cirrus_vga_enabled = 1;
int std_vga_enabled = 0;
int vmsvga_enabled = 0;
+int gfx_passthru = 0;
#ifdef TARGET_SPARC
int graphic_width = 1024;
int graphic_height = 768;
@@ -4269,6 +4271,7 @@ enum {
/* Xen tree: */
QEMU_OPTION_disable_opengl,
QEMU_OPTION_direct_pci,
+ QEMU_OPTION_gfx_passthru,
QEMU_OPTION_pci_emulation,
QEMU_OPTION_vncunused,
QEMU_OPTION_videoram,
@@ -4447,6 +4450,7 @@ static const QEMUOption qemu_options[] = {
#endif
{ "acpi", 0, QEMU_OPTION_acpi }, /* deprecated, for xend compatibility */
{ "direct_pci", HAS_ARG, QEMU_OPTION_direct_pci },
+ { "gfx_passthru", HAS_ARG, QEMU_OPTION_gfx_passthru},
{ "pciemulation", HAS_ARG, QEMU_OPTION_pci_emulation },
{ "vncunused", 0, QEMU_OPTION_vncunused },
{ "vcpus", HAS_ARG, QEMU_OPTION_vcpus },
@@ -5484,6 +5488,22 @@ int main(int argc, char **argv, char **envp)
case QEMU_OPTION_runas:
run_as = optarg;
break;
+ case QEMU_OPTION_gfx_passthru:
+ gfx_passthru = atoi(optarg);
+ switch (gfx_passthru) {
+ case GFX_NO_PASSTHRU:
+ break;
+ case GFX_IGD_PASSTHRU:
+ fprintf(logfile, "IGD graphics card assignment\n");
+ break;
+ case GFX_DISCRETE_PASSTHRU:
+ fprintf(logfile, "Discrete graphics card assignment\n");
+ break;
+ default:
+ fprintf(stderr, "unsupported gfx_passthru option: %d\n",
+ gfx_passthru);
+ }
+ break;
}
}
}
@@ -5897,13 +5917,17 @@ int main(int argc, char **argv, char **envp)
exit(1);
xenstore_write_vncport(vnc_display_port);
}
+
+ if (gfx_passthru == GFX_NO_PASSTHRU)
+ {
#if defined(CONFIG_SDL)
- if (sdl || !vnc_display)
- sdl_display_init(ds, full_screen, no_frame, opengl_enabled);
+ if (sdl || !vnc_display)
+ sdl_display_init(ds, full_screen, no_frame, opengl_enabled);
#elif defined(CONFIG_COCOA)
- if (sdl || !vnc_display)
- cocoa_display_init(ds, full_screen);
+ if (sdl || !vnc_display)
+ cocoa_display_init(ds, full_screen);
#endif
+ }
}
}
dpy_resize(ds);
--
1.6.0.4

3) intel-gfx-passthru-patch03.patch

Manually generated by Teo En Ming (Zhang Enming) on 29 August 2009 Saturday at 11:10 A.M. Singapore Time
Email #1: enming.teo@xxxxxxxxxxxxxxx
Email #2: space.time.universe@gmail.com
MSN: teoenming@hotmail.com

--- Makefile 2009-08-29 10:57:28.072084001 +0800
+++ Makefile 2009-08-29 11:03:30.650209241 +0800
@@ -50,6 +50,7 @@
roms.h: ../rombios/BIOS-bochs-latest ../vgabios/VGABIOS-lgpl-latest.bin \
../vgabios/VGABIOS-lgpl-latest.cirrus.bin ../etherboot/eb-roms.h
sh ./mkhex rombios ../rombios/BIOS-bochs-latest > roms.h
+ sh ./mkhex vgabios_pt ../vgabios/vgabios-pt.bin >> roms.h
sh ./mkhex vgabios_stdvga ../vgabios/VGABIOS-lgpl-latest.bin >> roms.h
sh ./mkhex vgabios_cirrusvga \
../vgabios/VGABIOS-lgpl-latest.cirrus.bin >> roms.h
--- hvmloader.c 2009-08-29 10:58:52.679084845 +0800
+++ hvmloader.c 2009-08-29 11:07:40.763119203 +0800
@@ -688,10 +688,10 @@
vgabios_sz = round_option_rom(sizeof(vgabios_stdvga));
break;
case VGA_pt:
- printf("Loading VGABIOS of passthroughed gfx ...\n");
- vgabios_sz =
- round_option_rom((*(uint8_t *)(VGABIOS_PHYSICAL_ADDRESS+2)) * 512);
- break;
+ printf("Loading Gfx Video BIOS from file ...\n");
+ memcpy((void *)VGABIOS_PHYSICAL_ADDRESS, vgabios_pt, sizeof(vgabios_pt));
+ vgabios_sz = round_option_rom(sizeof(vgabios_pt));
+ break;
default:
printf("No emulated VGA adaptor ...\n");
break;

My Own Patch to Fix Xen 3.5-unstable ACPI Code Build Issue with Intel ACPI Component Architecture compiler version 20090730
=================================================================================================

4. enming-patch04.patch

Patch created by Teo En Ming (Zhang Enming) on 29 August 2009 Saturday at 8:00 P.M. Singapore Time
Email #1: enming.teo@xxxxxxxxxxxxxxx
Email #2: space.time.universe@gmail.com
MSN: teoenming@hotmail.com
Mobile Phone: +65-9648-9798

--- ssdt_pm.h 2009-08-29 19:54:52.653088000 +0800
+++ ssdt_pm.h 2009-08-29 19:56:51.813088550 +0800
@@ -10,7 +10,7 @@
* C source code output
*
*/
-unsigned char AmlCode[] =
+unsigned char AmlCode_PM[] =
{
0x53,0x53,0x44,0x54,0xD6,0x05,0x00,0x00, /* 00000000 "SSDT...." */
0x02,0xB9,0x58,0x65,0x6E,0x00,0x00,0x00, /* 00000008 "..Xen..." */
--- ssdt_tpm.h 2009-08-29 19:55:44.578738954 +0800
+++ ssdt_tpm.h 2009-08-29 19:57:27.896638884 +0800
@@ -10,7 +10,7 @@
* C source code output
*
*/
-unsigned char AmlCode[] =
+unsigned char AmlCode_TPM[] =
{
0x53,0x53,0x44,0x54,0x4C,0x00,0x00,0x00, /* 00000000 "SSDTL..." */
0x02,0x2A,0x58,0x65,0x6E,0x00,0x00,0x00, /* 00000008 ".*Xen..." */

Click here for technical discussions in the Xen developers mailing list (August 2009 entries)

nVidia Geforce 8400 GS PCI Express x16 VGA Pass Through to Windows XP Home 32-bit HVM Virtual Machine with Intel Desktop Board DQ45CB

2009-08-25T23:15:00.007+08:00

I have managed to do PCI-e VGA passthrough with the open source Xen but the work is still in progress because although Windows XP guest can see the REAL PCI-e x16 graphics card instead of an emulated graphics driver, it cannot be initialized yet.

Thanks to Intel Engineer Han Weidong, Pasi Kärkkäinen, Boris Derzhavets, Marc, Caz Yokoyama, and others who have helped me and shared their knowledge with me along the way.

System Configuration:

Intel Desktop Board DQ45CB with BIOS upgraded to 0093
Onboard Intel GMA 4500 Graphics (IGD)
nVidia Geforce 8400 GS PCI Express x16 Graphics Card

Fedora 11 Linux 64-bit Xen paravirt operations Domain 0 Host Operating System
Xen 3.5 Unstable/Development Type 1 Hypervisor
Jeremy Fitzhardinge's Xen paravirt-ops domain 0 Kernel 2.6.31-rc6

BIOS Configuration:

Primary Video Adapter: IGD
Intel Virtualization Technology (VT): Enabled
Intel Virtualization Technology for Directed I/O (VT-d): Enabled

Please see screenshots below:

Click here for technical discussions on the Xen developers mailing list (August 2009 entries)

Xen Paravirt Operations Domain 0 Serial Console Testing

2009-08-25T00:03:00.004+08:00

My Intel Desktop Board DQ45CB Arrives from Amazon.com USA!

2009-08-16T14:47:00.018+08:00

I paid for this Intel Desktop Board DQ45CB from Amazon.com at SGD$177. It arrived in Singapore on 13 August 2009 Thursday.

You can't find this particular model anywhere in Singapore. This motherboard has the Intel Express Q45 chipset which supports Intel Virtualization Technology for Directed Input/Output (VT-d). Intel X58 chipset also supports VT-d but the Core i7 and motherboard bundles currently selling in Sim Lim Square (SLS) in Singapore are too expensive.

Then I made a visit to Sim Lim Square (SLS) in Singapore on the evening of 14 August 2009 Friday after work to buy this Intel Pentium Dual Core E6300 microprocessor at SGD$130. Pardon my frugality but I am too poor to afford the Intel Core 2 Duo series processors. I am not earning a lot.

I also bought this PCI 32-bit (note: it is not AGP or PCI Express x16) graphics card (ATI Rage 128 32 MB) for SGD$40 at SLS.

As I need lots of physical memory to run the open source Xen-based virtual machines, I made the decision to purchase two sticks of 2 GB DDR2-800 MHz memory. This is in addition to 2 sticks of 2 GB DDR2-800 MHz memory I already have running on my existing AMD Ahtlon 64 X2 Dual Core 4800+ Socket AM2 system, which I will be decommissioning later. So in total I will have 8 GB of memory.

DDR2 memory is dirt cheap nowadays.

My Windows Server 2003 Standard Edition 32-bit HVM Virtual Machine on Xen 3.4.1 RC8 Dom 0 Kernel 2.6.30 RC6 on OpenSUSE 11.1 Linux 32-bit Host

2009-07-29T12:11:00.007+08:00

My Windows XP HVM Virtual Machine on Xen 3.4.1 RC8 Dom 0 Kernel 2.6.30 RC6 on OpenSUSE 11.1 Linux 32-bit Host Operating System

2009-07-28T18:43:00.007+08:00

My Windows 7 HVM Virtual Machine on Xen 3.4.1 RC8 Dom 0 Kernel 2.6.30 RC6 on OpenSUSE 11.1 32-bit Linux Host Operating System

2009-07-28T12:47:00.007+08:00

Virtualization for Windows 7 using Xen hypervisor is pretty straight forward...

]

I/O Virtualization with Intel's VT-d

2009-07-27T00:49:00.007+08:00

VT-d = Intel Virtualization Technology for Directed Input/Output

Intel VT-d allows paravirtualized operating systems to access hardware devices on the host operating system directly. It eliminates hardware device emulation and improves I/O performance for the virtual machine tremendously. Intel's VT-d technology is analogous to AMD's IOMMU.

Article: Intel® Virtualization Technology for Directed I/O (VT-d): Enhancing Intel platforms for efficient virtualization of I/O devices

URL: http://software.intel.com/en-us/articles/intel-virtualization-technology-for-directed-io-vt-d-enhancing-intel-platforms-for-efficient-virtualization-of-io-devices/

I/O Virtualization with AMD's IOMMU

2009-07-26T21:42:00.002+08:00

AMD = Advanced Micro Devices
IOMMU = Input/Output Memory Management Unit

In short, IOMMU allows paravirtualized guest operating systems to access physical devices in the host 0perating system directly. You can pass through PCI devices in the host operating system to the virtual machine.

Article: I/O Virtualization and AMD's IOMMU

Author: Steve Apiki

URL: http://developer.amd.com/documentation/articles/pages/892006101.aspx

[QUOTE Steve Apiki]

VMMs such as VMWare and Xen have shown that you can build efficient virtual machines on x86 without hardware assistance. But working around the virtualization constraints of x86 introduces some significant software overhead—overhead that can be eliminated with some architectural improvements at a lower level.

AMD's AMD-V hardware virtualization technology, an AMD64 extension, puts the first hardware pillar under these VMMs by providing, effectively, a super-privileged operating mode in which VMMs can control guest operating systems. We've discussed AMD-V in an earlier article.

The second pillar will be hardware support for virtual I/O. In February, AMD published an I/O virtualization specification that outlines a design for a device called an IOMMU (I/O Memory Management Unit). Implementations of this design will be fielded as part of support chipsets, expected in 2007. When those implementations arrive, VMMs will be able to use IOMMU hardware to provide faster, more direct, and more secure access to physical devices from software running on guest operating systems.

Current VMMs must route I/O requests from guest OS drivers through the VMM, using emulated devices. They do this both to manage access to common memory space and to restrict real device access to kernel mode drivers. AMD's IOMMU design eliminates both of these constraints by providing DMA address translation and permission checking for device reads and writes. With an IOMMU, an unmodified driver in a guest OS can directly access its target device, without the overhead of running through the VMM, and without device emulation.

What's an IOMMU?
An IOMMU manages device access to system memory. It sits between peripheral devices and the host, translating addresses from device requests into system memory addresses and checking appropriate permissions on each access.

Typically, AMD's IOMMU will be deployed as part of a HyperTransport or PCI bridge device. In high-end systems where there may be multiple HyperTransport links between CPU(s) and I/O hubs, there will need to be multiple IOMMUs as well.

Existing AMD64 devices already include a more limited address translation facility, called a GART (Graphics Address Remapping Table), right on chip. The on-chip GART has been used for device address translation in existing systems, and is sometimes itself referred to as an IOMMU (especially in discussions of the Linux kernel), which can lead to confusion between the existing GART and the new IOMMU specification that we're discussing here.

The GART was originally designed to allow graphics chips to read textures directly from system memory, using address translation to gather allocations in system memory into a contiguous region mapped to an address that the graphics device could see. But the GART has also been put to use by Linux kernel programmers to enable legacy 32-bit PCI devices to access regions of system memory outside of their addressable range. This is done by programming the device to work inside the "graphics aperture" memory region controlled by the GART, and then using the GART to translate this address to the real target address, above 4 GB.

The new IOMMU can do this trick, too, only without the restrictions of the GART (which, after all, wasn't designed for this purpose). While the GART is limited to working inside the graphics aperture, the IOMMU can translate any address presented by the device to a system address.

More important, the IOMMU provides protection mechanisms that restrict device access to memory, whereas the GART performs translation only. It's the combination of address translation and access protection that makes the IOMMU so valuable for virtualization.

Translation and Protection
With the IOMMU, each device is assigned a protection domain. The protection domain defines the I/O page translations that will be used for each device in the domain, and specifies the read/write permissions for each I/O page. For virtualization, VMMs can assign all devices assigned to a given guest OS the same protection domain, which will create a consistent set of address translations and access restrictions used by all the devices running under a given guest OS.

Page translations are cached by the IOMMU in a TLB (Translation Lookaside Buffer). TLB entries are keyed by protection domain and by device request address. Because the protection domain is part of the cache key, cached addresses in the TLB are shared by all devices in the domain.

The IOMMU determines to what protection domain a device belongs, and then uses that domain and the device request address to look in the TLB. TLB entries contain read/write permission flags as well as the target system address for translation, so if an entry is found in the cache, the permission flags can be used to determine whether access is allowed or not.

For addresses that are not in the cache (for a given domain), the IOMMU moves on and looks through the I/O page tables associated with the device. I/O page table entries also contain permission information linked to system addresses. (There are also additional permission flags that can be set at the device level, and on directory entries encountered through the lookup process.)

So, all address translation attempts either end in a successful lookup, in which case appropriate permission flags tell the IOMMU whether to allow or block access, or in an unsuccessful lookup, in which case, naturally, the translation attempt fails. Using the IOMMU, then, the VMM is able to control what system pages should be visible to each device (or group of devices in a protection domain), and to specify the read/write access permissions on each page for each domain. It does this by controlling the I/O page tables that the IOMMU uses for address lookups.

The twin functions of translation and protection provided by the IOMMU provide a way to operate devices almost completely from user code, without kernel mode drivers. Instead of using trusted drivers to control device access to system memory, the IOMMU can be used to restrict device DMA to memory allocated by a user process. Device memory access is still protected by privileged code, but it's the privileged code that sets up the I/O page tables, not the drivers.

We have to say "almost," above, because interrupt handlers still need to be run in kernel mode. One way to take advantage of the IOMMU would be to create a limited kernel mode driver that contained interrupt handlers and otherwise control the device from user code.

Direct Access
An IOMMU makes I/O virtualization more efficient by allowing VMMs to directly assign real devices to guest operating systems. It's not possible for a VMM to emulate the translation and protection functions of an IOMMU, because the VMM can't get between kernel-mode drivers running on the guest OS and the underlying hardware. So, in the absence of an IOMMU, VMMs instead present an emulated device to the guest OS. The VMM then translates the guest's requests, ultimately, into requests to the real driver running down on the host OS or on the hypervisor.

With an IOMMU, the VMM sets up the I/O page tables to map system physical addresses to guest physical addresses, sets up a protection domain for the guest OS, and then lets the guest OS proceed as usual. Drivers written for the real device run as part of the guest OS unmodified, unaware of the underlying translations. Guest I/O transactions are isolated from those of other guests by I/O mapping of the IOMMU.

The IOMMU doesn't support demand paging of system memory. It can't, because peripherals can't be told to retry an operation, which would be required to deal with page loads. DMA transfers to pages that are not present will simply fail. Since the VMM can't know what pages will be DMA targets, the VMM is required to lock the entire guest in memory in order to work with peripherals through the IOMMU.

It's clear that AMD's IOMMU will make a big difference in virtualization overhead for I/O devices, by removing device emulation, by removing layers of translations, and by allowing native drivers to work with devices directly. It will be exciting to see what kind of performance results when this technology gets in the hands of VMM programmers.

Steve Apiki is senior developer at Appropriate Solutions, Inc., a Peterborough, NH consulting firm that builds server-based software solutions for a wide variety of platforms using an equally wide variety of tools. Steve has been writing about software and technology for over 15 years.

[/QUOTE]

Upcoming Xen 4.0 May Provide Full Support for AMD's IOMMU

2009-07-26T21:30:00.003+08:00

Click here for Xen Roadmap

[QUOTE]

Xen Product Roadmap

Xen 3.4 is now live. The following features/enhancements are proposed for Xen 4.0; see the complete community list at Xen.org Wiki Roadmap:

RDMA Live Migration Support
Dom0 kernel in Linux 2.6.30 or later
Dom0 support for Marvell 6480 disk driver
Pass through USB-Controllers/Devices for PV Guests
Fault Tolerance - Project Remus and/or Kemari
Monitor, Limit, Control network traffic coming at DomUs
Internationalization / Unicode Support
Configure Virtual Bridge like Real Switch (e.g. Control VLAN, port status)
VLan tagging per NIC int he VM Config File
Virtual Ethernet Switch
Physical Xen boot/install support via native UEFI (pUEFI) and virtual UEFI (vUEFI) support
Limit I/O for individual disks of VM (similar to credit scheduler weight)
Dynamic Memory Management for Overcommiting RAM
PCI CGA Passthrough for VT-d (vendor cards like Nvidia, AIT, etc)
Full AMD IOMMU Support
Online resizing of DomU Disks
Cross compliling Xen and Modular Builds

If you are interested in new features, please submit your ideas for Xen 4.0 to the xen-devel mailing list.

[/QUOTE]

Click here for Xen 4.0 Feature Requests List

[QUOTE]

Here is the active Xen 4.0 Feature Requests

Robert Dunkley (Robert@saq.co.uk) - RDMA Live Migration Support (allow for faster and smoohter live migration when

using Infiniband or Iwarp NICS)

Luke Crawford (lsc@prgmr.com) - Dom0 kernel in Linux 2.6.30 kernel and Marvell 6480 disk driver
Franz Von Hahn [franz.vonhahn@yahoo.de] - stable support for passing through usb-controllers/devices and pci-devices for paravirtualized guests would be really great.
Fault Tolerance - Project Remus and/or Kemari
Kashif Ali (kashif_quaidian@hotmail.com) - Monitor, Limit, & Control network traffic coming at DomUs
Nathan Stratton [nathan@robotics.net] - RDMA infiniband support for migration
Ramachandran Radhakrishnan [rama.radha@gmail.com] - Internationalization / Unicode support
Alessandro R. [lord2y@gmail.com] - A tool that permit to configure virtual bridge like real switch (e.g.

control VLAN, port status etc.); VLan tagging per NIC in the VM config file; Xen with a Virtual Ethernet Switch (like VDE2)? You can create a switch per client ; from Kieran Mansley [kmansley@solarflare.com] : With Xen (and other virtualisation technologies) users often end up with a set of bridges, v-switches, hardware switches, and now switches (albeit limited in capabilities) in virtualisation-aware NICs. It would be very useful to develop a control plane over all these devices to allow them to be sensibly configured from a single point. I know there are some people working on bits of this problem but bringing it all together to work on Xen, using open APIs and protocols so that other technologies could be easily integrated, would help a lot.

Dong Wei (dong.wei@hp.com) - the physical Xen boot/install support via native UEFI (pUEFI) and virtual UEFI (vUEFI) support
Thiago Camargo Martins Cordeiro [thiagocmartinsc@gmail.com]- Virtual Ethernet Switch, virtual uplinks (through SSH, for example), virtual cables, virtual plugs, so I can create a virtual switch per client on each of my dom0 of my cluster, or maybe it needs a easy way to integrate itself with VDE2.
Philipp Schmid (schmidp@schmidp.com) - Limit I/O for individual disks of VM (similar to credit scheduler weight)
Francesco Gallo (cluster@xinet.it) - Dynamic Memoery Management for Overcommitting RAM
Sander Eikelenboom [linux@eikelenboom.it] - as many others .. VGA (pci-e/pci) passthrough, complete USB passthrough, (also working for webcams/videograbbers etc) ; i'm currently working with "USB over IP" from the http://usbip.sourceforge.net/ project. It is working fine for printers/scanners, and almost perfect for webcam (some little distortion left). But functionality within XEN would be better.
Paul Schulze [avlex@gmx.net] - Fully functional USB passthrough would be really nice to have, but to be useful, I would also like to also request some sort of device management, that allows automatically assigning devices to a DomU whenever it is connected and a way to have unknown devices assigned to a default DomU. Otherwise, interaction on the Dom0 will be needed for each and every time, a device is connected; Comments form Sander Eikelenboom [linux@eikelenboom.it] Good point, some good and flexible management would be nice to have too. USBIP at the moment can handle:

- remove binding to currently loaded modules - binding to usbip at plugin time In some quite simple userspace management tools. For xen it think xend would be the place for normal rules, and xm for hotplug ? It would be nice if you could make the rules for usb passthrough match with both usb port numbers as well as device id's, perhaps even with wildcards.

Tim Moore (timothy.moore@expidas.net) - PCI CGA Passthrough for VT-d (vendor cards like Nvidia, AIT, etc);
- XCI Workaround in Xen (Jean Guyader - jean.guyader@gmail.com)
Paul Schulze (avlex82@googlemail.com) - Full AMD IOMMU SUpport
Pasi Karkkainen (pasik@iki.fi) - Online resizing of DomU Disks - see
- http://lists.xensource.com/archives/html/xen-devel/2008-09/msg00158.html http://lists.xensource.com/archives/html/xen-users/2008-04/msg00246.hhtml
Mike Dickson (mike.dickson@hp.com) - I'd like to see some emphasis put on cross compiling Xen and modular builds. I
- have a functional environment now cross compiling Xen 3.3.1 using the OpenEmbedded tool stack (this was inspired by the XenClient work and buildroot but my work is focused on the server side). Getting it to work was a bit of a challenge (and a few patches) as not all the pieces are really designed to be split apart and cross-compiled separately. The current approach which downloads all the separate bits is nice for some cases but ideally I'd like to be able to separately build the various pieces in modular fashion. And cross compile it as well so I can control the compilation environment separately from what the build host is running.

[/QUOTE]

Linux Kernel 2.6.30.3 Released!

2009-07-26T16:41:00.005+08:00

Click here to download the full source code for kernel 2.6.30.3

Changelog: http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.30.3

Microsoft Releases Device Driver Source Code for Inclusion into the Linux Kernel

2009-07-25T19:21:00.001+08:00

Article: Microsoft Patches Linux; Linus (Torvalds) Responds

Author: Christopher Smart

Date: Wednesday, July 22nd, 2009

URL: http://www.linux-mag.com/cache/7439/1.html

[QUOTE Christopher Smart]

You may have already heard, but the unthinkable has happened. That’s right, Microsoft, the self-proclaimed enemy of Linux and free software, has announced that they will be submitting some 20,000 lines of code to the Linux kernel. Come again? Yes, Microsoft wants to get its code into the Linux kernel. You read that right!

---snipped---

So why the patch? Well, it contains three drivers which will enhance the performance of Linux when virtualized as a guest under Microsoft’s virtualization product, Hyper-V. Ahh, now the truth starts to emerge. The purpose of the code has nothing to do with being generous, but rather it is to ensure that Linux will run well under their own virtualization technology. Microsoft has well realized that the world is moving towards free software and that users are implementing Linux in their infrastructure.

---snipped---

A smart (and necessary) move on Microsoft’s half in order to help stifle the migration of their clients to Linux. Microsoft knows that their clients want to virtualize Linux servers and currently they can’t do that very well on Microsoft hosts using Hyper-V. So if Microsoft does nothing, their clients will start to move away from running Microsoft Windows as their host operating system.

---snipped---

It is not a change of heart. Microsoft has not embraced Linux, or the GPL, or free software. This move is purely a strategic one in order to remain in the virtualization race. Microsoft only does things which are in their own best interest (as with every corporation) and this is no exception.

...

Much of their new found attention to open source has been a direct result of the European Commission’s Anti-trust case, which has forced them to open source certain products and release technical documentation.

---snipped---

Having said all that, it is amazing that Microsoft would even consider releasing software under the GPL. Who would have thought even one year ago that they would ever contribute code to Linux, even if it was for their own benefit? So on that level it is amazing indeed. What this patch does show is that Linux and free software is gaining in power and popularity, so much so that Microsoft can no longer ignore it.

---snipped---

So yes, Microsoft’s code is a calculated and purely selfishly motivated move, but that’s nothing new to the free software world. Sure, we should remember who Microsoft are and what their goals are but as Linus puts it, this is how everyone gets into open source in the first place.

---snipped---

Microsoft knows free software is not going anywhere and it needs this code in the kernel to stay in the game. They must ensure that Linux will run on their products, else they run the risk of losing the lot. What Microsoft has yet to realize, is that they are fighting a losing battle. This is a prime example of that fact and should be a wake up call to the giant.

[/QUOTE]

Creating OpenSolaris UNIX 2009.06 32-bit Paravirtualized DomU on Xen 3.4.1-rc8 Dom 0 pvops enabled Kernel 2.6.30-rc6 on OpenSUSE Linux 11.1 32b Host

2009-07-25T03:59:00.012+08:00

As at 25 July 2009 Sat 4:03 A.M. SGT: Work in progress...

Guest domain configuration adapted using Boris Derzhavets' configuration howto:

As at 27 July 2009 Mon 12:49 P.M. SGT: Work in progress...

OpenSolaris 2009.06 virtualization successful!

As at 27 July 2009 Mon 9:36 P.M. SGT: Enabling the GNOME Desktop Environment GUI

I have followed the instructions here:

Tim Thomas's Blog

OpenSolaris Bug 125

Static IP Configuration

Download Manager for Linux: KDE's KGet

2009-07-24T17:13:00.000+08:00

Creating CentOS 4.7 32-bit Paravirtualized Guest under OpenSUSE 11.1 Linux (Jeremy's git branch) paravirt-ops enabled Xen Dom 0 Kernel

2009-07-23T21:32:00.000+08:00

Click Here: Collaboration with members of the xen-devel mailing list community to get my Xen Dom 0 paravirt-ops enabled kernel on OpenSUSE 11.1 x86-32 working

Click Here: My postings in the Xen developers mailing list

My Self-Compiled Paravirt-ops (pv_ops) enabled Xen Dom 0 Kernel (Jeremy's git branch) on 32-bit OpenSUSE 11.1 Linux

2009-07-23T16:41:00.000+08:00

I based my Xen Dom 0 paravirt-ops enabled kernel (Jeremy Fitzhardinge's git branch) configuration, compilation and installation on OpenSUSE 11.1 32-bit Linux using Boris Derzhavets's howto:

Article: Setup Fedora 11 PV DomU at Xen 3.4.1 Dom0 (kernel 2.6.30-rc6-tip) on top of Fedora 11
URL: http://bderzhavets.wordpress.com/2009/06/10/setup-fedora-11-pv-domu-at-xen-3-4-1-dom0-kernel-2-6-30-rc6-tip-on-top-of-fedora-11/

Click Here: My postings in the Xen developers mailing list

Singapore Citizen Mr. Teo En Ming (Zhang Enming)

Announcing the Release of the World’s First 64-bit Build of Google’s ChromiumOS for Netbooks

Video of Google Chrome OS (ChromiumOS) in Action on VMware Workstation and Sun VirtualBox as a Virtual Machine

Latest Google Chrome OS (ChromiumOS) VMware VMDK Image File Download: Guaranteed to Work!

Google Chrome OS Download

Video of Google Chrome OS (Chromium OS) on Xen

Picture Tutorial: How to DIY your own Google Chrome OS with Xen-based Ubuntu 9.10 Karmic Koala amd64 Virtual Machine in Fedora 11 x86_64 Pv-Ops Dom0

Video Demo: Building a Rocks HPC Cluster with Xen Hardware Virtual Machines (HVM) (Update 1)

Video Demo: Building a Rocks HPC Cluster with Xen Hardware Virtual Machines (HVM)

Video Tutorial: How to Setup a Virtual Supercomputer Center or HPC Cluster using Xen Virtual Machines

Using Xen Virtualization Environment for Development and Testing of Supercomputing and High Performance Computing (HPC) Cluster MPICH2 Applications

Xen Virtualization: 2nd Iteration of the Super PI 32M Benchmark Test

Xen Virtualization, VT-d, VGA Passthrough, & Windows XP HVM Virtual Machine: Super PI 32M Benchmark

Xen Virtualization & Intel VT-d: Direct Hardware Access to Graphics Card by Windows HVM Virtual Machines

More Xen Virtualization VGA Passthrough Videos

Xen PV-OPS Dom0 Kernel 2.6.31.4 Testing

IEEE 1394a Firewire Controller Passthrough Work in Progress

pvops dom0 kernel 2.6.31.1 Build Successful

Xen Virtualization: Playing 3D Accelerated FPS Games in Windows XP Virtual Machine

USB Device Pass Through Succeeded

PVOPS Dom 0 kernel 2.6.31 and Mainline Kernel 2.6.31

Disabled all USB support in the kernel...

UHCI, OHCI, EHCI, and xHCI disabled...

Disabling USB 1.0, USB 2.0 Drivers and Enabling USB 3.0 Drivers

After disabling the USB 1.0 Host Controller Driver...

Error with pv-ops dom 0 kernel 2.6.31 final

Disk I/O Benchmark Results with Xen-based Windows XP Home HVM Virtual Machine

The Final Solution: PCI Express x16 Graphics Card Passthrough to Windows XP Home Edition 32-bit HVM Virtual Machine

Video Presentation on PCI Express x16 VGA Passthrough to Xen-based Windows XP Home HVM Virtual Machine

Windows XP Home DomU Test Results after applying Intel's VGA Passthrough Patchset to Xen 3.5-unstable

nVidia Geforce 8400 GS PCI Express x16 VGA Pass Through to Windows XP Home 32-bit HVM Virtual Machine with Intel Desktop Board DQ45CB

Xen Paravirt Operations Domain 0 Serial Console Testing

My Intel Desktop Board DQ45CB Arrives from Amazon.com USA!

My Windows Server 2003 Standard Edition 32-bit HVM Virtual Machine on Xen 3.4.1 RC8 Dom 0 Kernel 2.6.30 RC6 on OpenSUSE 11.1 Linux 32-bit Host

My Windows XP HVM Virtual Machine on Xen 3.4.1 RC8 Dom 0 Kernel 2.6.30 RC6 on OpenSUSE 11.1 Linux 32-bit Host Operating System

My Windows 7 HVM Virtual Machine on Xen 3.4.1 RC8 Dom 0 Kernel 2.6.30 RC6 on OpenSUSE 11.1 32-bit Linux Host Operating System

I/O Virtualization with Intel's VT-d

I/O Virtualization with AMD's IOMMU

Upcoming Xen 4.0 May Provide Full Support for AMD's IOMMU

Xen Product Roadmap

Linux Kernel 2.6.30.3 Released!

Microsoft Releases Device Driver Source Code for Inclusion into the Linux Kernel

Creating OpenSolaris UNIX 2009.06 32-bit Paravirtualized DomU on Xen 3.4.1-rc8 Dom 0 pvops enabled Kernel 2.6.30-rc6 on OpenSUSE Linux 11.1 32b Host

Download Manager for Linux: KDE's KGet

Creating CentOS 4.7 32-bit Paravirtualized Guest under OpenSUSE 11.1 Linux (Jeremy's git branch) paravirt-ops enabled Xen Dom 0 Kernel

My Self-Compiled Paravirt-ops (pv_ops) enabled Xen Dom 0 Kernel (Jeremy's git branch) on 32-bit OpenSUSE 11.1 Linux