HOW-TO make dual-boot obsolete using XEN VGA passthrough

[GizmoChicken]

@powerhouse:

You wrote the bulk of your original tutorial based on your experiences with Xen 4.1 which, if I'm not mistaken, uses xm/xend as its default toolstack. Have you tried configuring VGA/PCI passthrough with Xen 4.2, which uses xl as its default toolstack? If so, were any modifications to your original tutorial needed?

P.S. Just another "Thanks!" for such a great tutorial. And I agree with your choice not to open new threads, but rather to post updates to the same thread. Much better to keep all the info in one thread.

[powerhouse]

@powerhouse:

You wrote the bulk of your original tutorial based on your experiences with Xen 4.1 which, if I'm not mistaken, uses xm/xend as its default toolstack. Have you tried configuring VGA/PCI passthrough with Xen 4.2, which uses xl as its default toolstack? If so, were any modifications to your original tutorial needed?

P.S. Just another "Thanks!" for such a great tutorial. And I agree with your choice not to open new threads, but rather to post updates to the same thread. Much better to keep all the info in one thread.

The entire tutorial is based on Xen 4.1, the one delivered with Linux Mint 13. In the meantime Linux Mint 14 has been released and I downloaded it to give it a try. It still ships with Xen 4.1, and, as far as I know, doesn't have an LVM option for the installation, though it does come with LVM and recognizes preformated LVM volumes. I didn't see any point in doing any further trials or installation, as long as it doesn't ship with Xen 4.2.

At some point in my trial and error process - mainly getting a Nvidia Quadro 600 card to pass through - I downloaded the 4.2 hypervisor and compiled it. Eventually after 2 trials it didn't complain. However, I gave up when I didn't succeed in inserting the graphics card BIOS, a procedure that is needed for Nvidia cards that don't have native passthrough capability (the majority of Nvidia cards). So, I can't really speak about the new xl toolstack.

It's supposedly better and making things easier. But I really don't know if it improves compatibility with hardware, and the lesson I learned is that it's the hardware: If you got the right stuff, it just works. I eventually replaced the Quadro 600 for a Quadro 2000 (and threw in a bunch of money) and everything works.

By the way, did you manage to make it work?

EDIT: In the meantime I updated to Linux Mint 14, running Xen hypervisor 4.1.3.

P.S.: Yeah, thanks. But I will have to abide the admins. It's their call.

[GizmoChicken]

I downloaded the 4.2 hypervisor and compiled it. Eventually after 2 trials it didn't complain. However, I gave up when I didn't succeed in inserting the graphics card BIOS, a procedure that is needed for Nvidia cards that don't have native passthrough capability (the majority of Nvidia cards). So, I can't really speak about the new xl toolstack.

Thanks much for the reply. Yep, I thought that I remembered reading somewhere that you tried 4.2. I probably won't be upgrading to 4.2 anytime soon. Mostly just wondering what to expect when I do.

By the way, did you manage to make it work?

Yes, I briefly tested my AMD 6670 using VGA-passthrough with an HVM domU, and it worked great following your tutorial. Thanks!

For now, however, my only graphical desktop is dom0, with all my guests being non-graphical servers and so without any need for VGA-passthrough. But I'm currently trying to figure out how to configure PCI-passthrough with a domU hosted on an XCP server. (XCP provides a user-friendly means for GPU-passthrough, but curiously, requires extensive tweaking to get PCI-passthrough working.)

If I can get PCI passthough working in XCP, I will passthrough nearly all of my USB controllers, along with a second PCI video card, to an HVM guest running Ubuntu desktop. That way, I'll have, on a single machine, both a stable XCP server (which I could leave up 24/7 to host my virtual servers) and also local access to a virtual machine having a fully functional desktop (which I could shut down when not in use).

Although XCP uses the xe toolstack, which is very different from the xl/xm toolstack, your tutorial has been immensely helpful in bringing me up to speed with PCI-passthrough concepts. Thanks again!

And if I can't get PCI passthough working in XCP, I'll eventually rebuild my system using a server based (non-graphical) distribution for dom0 and then move my only desktop to a domU, in which case, I'm sure I'll be relying heavily on your tutorial again in the future.

Yeah, thanks. But I will have to abide the admins.

Have you considered submitting your tutorial to the HowTo section of the Xen wiki?

[powerhouse]

Yes, I briefly tested my AMD 6670 using VGA-passthrough with an HVM domU, and it worked great following your tutorial. Thanks!

For now, however, my only graphical desktop is dom0, with all my guests being non-graphical servers and so without any need for VGA-passthrough. But I'm currently trying to figure out how to configure PCI-passthrough with a domU hosted on an XCP server. (XCP provides a user-friendly means for GPU-passthrough, but curiously, requires extensive tweaking to get PCI-passthrough working.)

If I can get PCI passthough working in XCP, I will passthrough nearly all of my USB controllers, along with a second PCI video card, to an HVM guest running Ubuntu desktop. That way, I'll have, on a single machine, both a stable XCP server (which I could leave up 24/7 to host my virtual servers) and also local access to a virtual machine having a fully functional desktop (which I could shut down when not in use).

Although XCP uses the xe toolstack, which is very different from the xl/xm toolstack, your tutorial has been immensely helpful in bringing me up to speed with PCI-passthrough concepts. Thanks again!

And if I can't get PCI passthough working in XCP, I'll eventually rebuild my system using a server based (non-graphical) distribution for dom0 and then move my only desktop to a domU, in which case, I'm sure I'll be relying heavily on your tutorial again in the future.

Yeah, thanks. But I will have to abide the admins.

Have you considered submitting your tutorial to the HowTo section of the Xen wiki?

Thanks for the reply. I'm glad the tutorial helped and you made it work.

I have no experience with XCP, though I did consider it but felt it would be overkill for running a single PC.

At first I wanted to run a non-graphical Xen server with Linux Mint and Windows 7 as domUs. But there is some convenience to having a graphical dom0 and I was pleasantly surprised at how easy it was to install and run the Xen hypervisor in Linux Mint (OK, the LVM installation required some experimenting, but that's a different tutorial).

Re posting to the Xen wiki: I'd gladly do that! I tried to sign up to Xen but could only find a mailing list option . I'm not going to sign up to any mailing list. Do you have any experience with that? Like to share a link or advise?

EDIT: Just signed up at wiki.xen.org ! Now I just need to figure out how to write and post a Wiki.

[powerhouse]

EDIT: I changed/improved my Windows start script and got rid of espeak. Instead I use matedialog / zenity to print screen messages. As a bonus, the new script doesn't require a password when launching Windows. See http://forums.linuxmint.com/viewtopic.php?f=42&t=112013&p=628918#p628918 for the new script! Below is the original post with the old script, for reference:

Until today I had placed a launcher on my desktop to run xm create /etc/xen/win7.cfg. The launcher didn't check if the Windows VM was already running or not, and instead of quitting without notice, or an error, I figured it wouldn't be too hard to come up with something.

So I installed espeak and the packages it needs and wrote the following simple script:

Code: Select all

#!/bin/sh

if xm list | grep -q win7; then
   espeak "windows is already running" 2> /dev/null
   exit 1

else

   xm create /etc/xen/win7.cfg &> /dev/null
   espeak "starting windows, please wait" 2> /dev/null
   exit 0

fi

The script must be invoked with root permission. To avoid having to enter a root password whenever I want to run it, I used the little C program (source code) presented here: http://www.tuxation.com/setuid-on-shell-scripts.html. Edit the path, compile, and follow the instructions on how to make it setuid. Of course I changed permissions to both this program and the script to allow only root to modify it.

EDIT: I found a bug with the above mentioned C program (as simple as it is) and now discourage using it. Please use the new script mentioned at the beginning of this message.

Enjoy!

Of course your speakers should be turned on.

[Nesousx]

Thanks a lot for this great tutorial Powerhouse, I followed it and it worked fine on Linux Mint 14. However I add to modify a symlink in order to make it work.

At some point I had the following error:

Could not read keymap file: '/usr/share/qemu/keymaps/en-us

In order to fix this I checked my files/folder "configuration" and I had to create a diffrent symlink than the one provided in several How Tos on the Internets. Here is what I did:

Code: Select all

sudo ln -s /usr/share/qemu-linaro/qemu/ /usr/share/qemu

So my Windows 7 booted without any issue, installation and PCI passthrough worked (score of 7.1).

However, I now have a problem I can't seem to fix.

I no longer can passthrough my devices.

It seems that the 3 devices I used to passthrough are no longer available: the following command returns nothing:

Code: Select all

sudo xm pci-list-assignable-devices

I didn't do any hardware change.

I can't find where those devices are used or attached... and I can't find anyway to release them.. Now when I want to run the HVM, I have the following error:

Error: pci: PCI Backend and pci-stub don't own device 0000:03:00.0

This ID corresponds to the HD7850 card (part without audio, and the 1st entry to passhtrough listed in my /etc/xen/win7.cfg).

What I did before I broke it:

1. I shutdown Windows 7 via the Start Menu > Shutdown.

2. Tried to use my Radeon as primary card under Linux and Windows HVM. So I installed AMD Drivers. I had the baclscreen after login you were talking about.. Couldn't figure out how to get through it, so I switched back to the Intel card for Linux and AMD for Windows HVM and removed the ATI Drivers. Since then it is broke.

What I find weird is that I also "lost" the PCI device that hosts the USB port... So i might not be related to the AMD Drivers screwing up something...

Edit: I fixed my problem!

I was really dumb.. After many tests I was able to release manually the PCI host, but couldn't release the graphic card... So I thought maybe the pciback script wasn't running. So i did a little:

Code: Select all

sudo /etc/init.d/pciback enable

And it worked like a charm... because yes I previously "disabled" it when I tried to use the AMD card under Linux..

Now, I'll try to get AMD card working on both Linux and Widows HVM.

Thanks again for your great howto!

[powerhouse]

Code: Select all

sudo ln -s /usr/share/qemu-linaro/qemu/ /usr/share/qemu

Thanks for this input - I'll update my how-to!

So my Windows 7 booted without any issue, installation and PCI passthrough worked (score of 7.1).

However, I now have a problem I can't seem to fix.

I no longer can passthrough my devices.

It seems that the 3 devices I used to passthrough are no longer available: the following command returns nothing:

Code: Select all

sudo xm pci-list-assignable-devices

I didn't do any hardware change.

I can't find where those devices are used or attached... and I can't find anyway to release them.. Now when I want to run the HVM, I have the following error:

Error: pci: PCI Backend and pci-stub don't own device 0000:03:00.0

This ID corresponds to the HD7850 card (part without audio, and the 1st entry to passhtrough listed in my /etc/xen/win7.cfg).

What I did before I broke it:

1. I shutdown Windows 7 via the Start Menu > Shutdown.

2. Tried to use my Radeon as primary card under Linux and Windows HVM. So I installed AMD Drivers. I had the baclscreen after login you were talking about.. Couldn't figure out how to get through it, so I switched back to the Intel card for Linux and AMD for Windows HVM and removed the ATI Drivers. Since then it is broke.

What I find weird is that I also "lost" the PCI device that hosts the USB port... So i might not be related to the AMD Drivers screwing up something...

Any help would be grealty appreciated.

I had a similar problem with the nouveau (Nvidia) driver - it would insist on loading and grab my graphic card. Run as regular user:

Code: Select all

lspci -v | grep -A 10 VGA

This should list the VGA cards you got and towards the end the "Kernel driver in use:". See what's listed for your ATI card - it most certainly is not "pciback". Copy the name of the driver that grabs the VGA card and edit as root the /etc/modprobe.d/blacklist.conf file. Add the following line to the bottom:

Code: Select all

blacklist name-of-driver-you-got-from-lspci

In my case I created a separate file under /etc/modprobe.d called blacklist-nouveau.conf with a one-liner "blacklist nouveau" to blacklist my Nvidia card open-source driver that got in the way.

In your case it would probably be "blacklist radeon" or so.

About the other PCI devices you passed through and which aren't working now, let's solve the graphics card first.

You will also have to pass-through the audio part of the graphics card, in your case probably 0000:03:00.1 (you do have a sound device on that ATI card?).

Finally, check the pciback.conf and win7.cfg files under /etc/xen. See that the entries match.

Good luck and report back.

[Nesousx]

Code: Select all

sudo ln -s /usr/share/qemu-linaro/qemu/ /usr/share/qemu

Thanks for this input - I'll update my how-to!

So my Windows 7 booted without any issue, installation and PCI passthrough worked (score of 7.1).

However, I now have a problem I can't seem to fix.

I no longer can passthrough my devices.

It seems that the 3 devices I used to passthrough are no longer available: the following command returns nothing:

Code: Select all

sudo xm pci-list-assignable-devices

I didn't do any hardware change.

I can't find where those devices are used or attached... and I can't find anyway to release them.. Now when I want to run the HVM, I have the following error:

Error: pci: PCI Backend and pci-stub don't own device 0000:03:00.0

This ID corresponds to the HD7850 card (part without audio, and the 1st entry to passhtrough listed in my /etc/xen/win7.cfg).

What I did before I broke it:

1. I shutdown Windows 7 via the Start Menu > Shutdown.

2. Tried to use my Radeon as primary card under Linux and Windows HVM. So I installed AMD Drivers. I had the baclscreen after login you were talking about.. Couldn't figure out how to get through it, so I switched back to the Intel card for Linux and AMD for Windows HVM and removed the ATI Drivers. Since then it is broke.

What I find weird is that I also "lost" the PCI device that hosts the USB port... So i might not be related to the AMD Drivers screwing up something...

Any help would be grealty appreciated.

I had a similar problem with the nouveau (Nvidia) driver - it would insist on loading and grab my graphic card. Run as regular user:

Code: Select all

lspci -v | grep -A 10 VGA

This should list the VGA cards you got and towards the end the "Kernel driver in use:". See what's listed for your ATI card - it most certainly is not "pciback". Copy the name of the driver that grabs the VGA card and edit as root the /etc/modprobe.d/blacklist.conf file. Add the following line to the bottom:

Code: Select all

blacklist name-of-driver-you-got-from-lspci

In my case I created a separate file under /etc/modprobe.d called blacklist-nouveau.conf with a one-liner "blacklist nouveau" to blacklist my Nvidia card open-source driver that got in the way.

In your case it would probably be "blacklist radeon" or so.

About the other PCI devices you passed through and which aren't working now, let's solve the graphics card first.

You will also have to pass-through the audio part of the graphics card, in your case probably 0000:03:00.1 (you do have a sound device on that ATI card?).

Finally, check the pciback.conf and win7.cfg files under /etc/xen. See that the entries match.

Good luck and report back.

I fixed my problem and edited previous post. Now I ll try to have the amd card working on both linux and windows.

[powerhouse]

A couple of days ago I added a Transcend PDC3 USB 3.0 / SATA-III combo PCIe card to my box in order to hook up my last HDD (my internal Marvell SATA controller doesn't work with Xen, so I lost 2 SATA ports).

The card comes with an ASMedia ASM1062 SATA-III controller. After I hooked up the internal drive and booted the PC, the drive wasn't recognized. I couldn't find it anywhere, though the ASMedia SATA controller was listed.

Code: Select all

lspci -v | grep -A 11 -i sata

lists the SATA controllers with some extra details.

It turns out that I had passed through another onboard ASMedia SATA-III controller to be used under Windows. I planned to use this passed through eSATA port to hook up external eSATA disks under Windows, but never actually used it. So, either both of them run under Linux dom0, or under Windows. A pitty .

[powerhouse]

I fixed my problem and edited previous post. Now I ll try to have the amd card working on both linux and windows.

I'm glad you figured out the problem - there are quite many steps and one glitch and boom goes the setup.

If you make it work, please post some instructions.

[Nesousx]

I fixed my problem and edited previous post. Now I ll try to have the amd card working on both linux and windows.

I'm glad you figured out the problem - there are quite many steps and one glitch and boom goes the setup.

If you make it work, please post some instructions.

I will report here if I am successful, however I won't be able to try before a week or so.

[powerhouse]

...Edit: I fixed my problem!

I was really dumb.. After many tests I was able to release manually the PCI host, but couldn't release the graphic card... So I thought maybe the pciback script wasn't running. So i did a little:

Code: Select all

sudo /etc/init.d/pciback enable

And it worked like a charm... because yes I previously "disabled" it when I tried to use the AMD card under Linux..

Now, I'll try to get AMD card working on both Linux and Widows HVM.

Thanks again for your great howto!

You probably mean:

Code: Select all

sudo /etc/init.d/pciback start

[powerhouse]

I ran across some user reports where newer BIOS software would disable/break VT-d support and thus render a system as described here unusuable. In fact, my Asus Sabertooth X79 motherboard is probably one of those motherboards where newer BIOS releases may break VT-d - see here http://vip.asus.com/forum/view.aspx?id=20120806185452699&board_id=1&model=SABERTOOTH+X79&page=1&SLanguage=en-us.

Some other boards that have been widely confirmed to work are - after new BIOS updates - likely to loose VT-d support - see ASrock Z77 Extreme4 and Extreme6 (EDIT: ASrock fixed VT-d support - check their BIOS release notes). I'm not sure why this is happening, but it may be related to UEFI secure boot and/or Microsoft Windows 8 compatibility (this is purely speculative). Here is what Asus writes on their webpage regarding BIOS upgrades:
"Important! In order to support full Windows 8 functionality, BIOS of your motherboard must be converted from ROM to CAP structure. Before you can update any .CAP BIOS file to your motherboard, you must execute BIOS Converter designed specifically for your motherboard. ..."

The Asus BIOS update notes refer to Windows 8 compatibility and improved stability, but do not mention any VT-d issues. I wrote to Asus tech support a couple of months ago after I read about the broken VT-d support (see first link above). Here is their answer to my questions (1. Linux support; 2. Marvell SATA controller not working under Xen; 3. BIOS update breaks VT-d):

"Dear Valued Customer,

Thank you for contacting ASUS Technical Service.

1. We don't officially support Linux on desktop motherboard. So, we don't have drivers to provide.

2. Maybe you haven't loaded Marvell controller driver.

3. We don't broke vt-d in new bios. As long as cpu could support vt-d, you could use vt-d.

Sorry for the trouble. Wish you a good day.

If you continue to experience issues in the future, please do not hesitate to contact us again.
Best Regards,
Cherry
ASUS Global Technical Support Center"

What does this answer mean? If I take answer 3 (VT-d works with new BIOS) and update the BIOS, all will be fine. And if not, read answer no. 1.

Let's take answer no. 2 and try to load the Marvell driver (which is, by the way, loaded automatically by Linux). If that doesn't work, read answer no. 1.

Let's have a look at answer no. 1: Linux not "officially" supported. Does it mean it's supported unofficially? Is there a secret Asus underground Linux cell? How do I get in touch with them, or is it dangerous to ask this question in public?

Now, to make things worse, the user cannot revert a BIOS update, at least not for Asus and ASrock (check their websites). If I had updated my BIOS, chances are I would have bricked my PC.

My recommendation: Buy hardware that's "officially" supported by the vendor as Linux compatible. While that still doesn't guarantee VT-d or Xen VGA passthrough support, you may have better chances to resolve any problems with the vendor.

A practical suggestion: Check out VMware "VMDirectPath" related posts such as this here http://communities.vmware.com/thread/400543. VMDirectPath is essentially PCI passthrough under VMware, so hardware that's supported under VMware is likely to work under Xen too.

[powerhouse]

I believe I mentioned that the local network file transfer speed was sub-optimal. I tried both Samba and NFS, neither of which really gave me the speed I hoped for. It also didn't matter whether it was from Linux dom0 to a networked computer, or from Windows domU to that computer.

Eventually I installed LM14 Mate but that didn't help. However, trying a long list of remedies, here is what I have now and it DID improve file transfer speed by some 150-700%:

1. Disable network-manager (see how-to);
2. Disable virbr NAT setup by deleting the "default.xml" link in etc/libvirt/qemu/networks/autostart;
3. Copy /etc/samba/smb.cfg to smb.conf.master, edit the latter and comment out:

Code: Select all

#;   name resolve order = lmhosts host wins bcast

then add:

Code: Select all

name resolve order = bcast host lmhosts wins

4. Run:

Code: Select all

sudo testparm -s smb.conf.master > smb.conf

5. After you installed the latest GPLPV drivers (0.11.0.357) inside Windows, including the network driver, edit the /etc/xen/win7.cfg file and change as follows:

Code: Select all

vif = [ 'vifname=win7,type=ioemu,mac=00:16:3e:68:e1:01,bridge=xenbr0' ]

to

Code: Select all

vif = [ 'mac=00:16:3e:68:e1:01,bridge=xenbr0' ]

Note: Remove the type=ioemu! vifname=... gave me an error, so I removed it too.
6. To disable Xen's network scripts (which is recommended), edit the /etc/xen/xend-config.sxp file and search for "network-script" lines and comment them out, then add "(network-script /bin/true)" so it looks like this:

Code: Select all

# (network-script network-bridge)
(network-script /bin/true)

7. To disable IPv6 (can cause slow network under Ubuntu/Linux Mint) edit /etc/sysctl.conf and add these lines to the bottom:

Code: Select all

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1

as well as these:

Code: Select all

net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0

to prevent the firewall (netfilter) from filtering bridged packets.
(8. This is a work around for Ubuntu bug #50093 to ensure that the bridge sysctl settings get loaded on boot. Edit the /etc/rc.local file and place the following line just above the line "exit 0":

Code: Select all

/sbin/sysctl -p /etc/sysctl.conf

I don't think this is necessary anymore, at least under LM14 it didn't make a difference.)
9. Restart your computer.

To test the file transfer speed, I created a 1 Gigabyte test file using:

Code: Select all

dd if=/dev/zero of=testfile.img count=1024 bs=1024M

I'm getting now ~26-30MByte file transfer speed on my Gigabit link to an old laptop, where before it topped at 4.5Mbyte. On a 100Mb link to my networked media tank (NMT) I get around 4.3MByte where before it would max at 2.5MByte.

EDIT: I added 2 more steps I had missed.
EDIT 2: Removed e1000 entry (under vif = ...) since GPLPV drivers don't use the e1000 (or any other) emulation.

[powerhouse]

For a long time I had a networking problem under Windows 7 which would cause Youtube videos to stop shortly after they start, pause for a while, and continue until they stop again shortly after. Also, I couldn't watch movies residing on a network drive. These were quite perplexing issues, and no matter what I tried, it didn't work.

It turned out to be an issue with the GPLPV drivers release 0.11.0.356. Today I downloaded and installed the latest 0.11.0.357 drivers under Windows 7 and all is fine now: Youtube video runs fine, so do videos on a network drive.

I've updated my instructions in the how-to and placed a new link to the download site for these drivers.

[earlboy]

Just want to say thanks you for this guide.

Currently running Linux Mint 14 MATE (Dom0) with Win7 64 bit (DomU).

Asrock Z77 Extreme 4, i7 3770
Intel HD graphics for Linux Mint Dom0.
2xSapphire 7970 VGA passthrough for Win7 DomU. ( Catalyst Control Center working, Crossfire working according to CCC)

Played Terra online for a few minutes as a test. No problems encountered. Will stress test as soon as Terra servers finish maintenance.

[earlboy]

Played for a few hours with no problems.

[powerhouse]

Just want to say thanks you for this guide.

Currently running Linux Mint 14 MATE (Dom0) with Win7 64 bit (DomU).

Asrock Z77 Extreme 4, i7 3770
Intel HD graphics for Linux Mint Dom0.
2xSapphire 7970 VGA passthrough for Win7 DomU. ( Catalyst Control Center working, Crossfire working according to CCC)

Played Terra online for a few minutes as a test. No problems encountered. Will stress test as soon as Terra servers finish maintenance.

Thanks for posting! It's great to hear that crossfire works as well. Wow, that must be quite some gaming rig you've got there. How is the Windows graphics performance versus bare metal? Any difference? Just curious.

[earlboy]

Just want to say thanks you for this guide.

Currently running Linux Mint 14 MATE (Dom0) with Win7 64 bit (DomU).

Asrock Z77 Extreme 4, i7 3770
Intel HD graphics for Linux Mint Dom0.
2xSapphire 7970 VGA passthrough for Win7 DomU. ( Catalyst Control Center working, Crossfire working according to CCC)

Played Terra online for a few minutes as a test. No problems encountered. Will stress test as soon as Terra servers finish maintenance.

Thanks for posting! It's great to hear that crossfire works as well. Wow, that must be quite some gaming rig you've got there. How is the Windows graphics performance versus bare metal? Any difference? Just curious.

Haven't done any benchmarks, but I feel no difference. Same experience when I was playing the game booted from windows.

By the way, I did another install of xen but this time my friends rig was using an ATI card made by MSI adn CCC crashed when I tried to install it. But, it runs fine, with the just the ATI drivers.

[Lomaxx]

This is an interesting topic. I am currently in the process of buying a new PC and considering to set something like this up for some gaming and running Propellerhead Reason in Windows, while keeping Linux as my main-os. As if buying a self-build PC isn't a complicated enough without this topic already. Well, I am not sure yet if I will try. Although this is a great step ahead, it's quite some effort with additional costs (two GPU-cards of a certain type). But I didn't come here for ranting.

I had the quick thought of using Synergy (synergy-foss.org/) instead of an USB-KVM. If i get the basics of Xen right, then both OS (e.g Linux and Windows) are running at the same time and not being switched while pausing the other. So it should work. Then you could move your mouse-pointer out of your monitors view, switch the monitor and continue to move the mouse and type on the same keyboard in the other OS. I'm not completely sure how well Synergy works for games, but so far my experiences with Synergy are pretty good. That would be one switch less you need to turn and especially more pleasing with a dual-monitor-setup (using one monitor for each OS).