Question about windows HVM

[bradbury9]

Hi,

I want to give qubes a try but actually dont have any decent hardware to try it on. On another side I am planning to get a gaming desktop computer so I was thinking maybe I could combine both needs (aka, gaming qubes). There go my questions...

- Could be possible to get a windows HVM with DirectX (9.0C) and big amount of RAM (minimum 6 GB)? If not, does default qubes installation allow dual boot?
- Any plans on allowing HVM get fullscreen or is there any security risk?
- Is it posible to get a templateVM (probably ubuntu or mint) with OpenGL?

BTW, you guys are doing a great job providing security to regular users.

[Joanna Rutkowska]

At this moment (Release 2) there are no plans to add DirectX/OpenGL/GPU
support for AppVMs. However, given the fact you're building a custom
desktop, you might try adding another GPU card and try to pass it
through one of the HVMs (I guess qvm-pci should do the work as with any
other PCIe device, although I never tried that). So you will want to
pass your powerful GPU to the HVM, and leave some old GPU at dom0 for
the standard Qubes desktop.

Do let us know if that worked or not!

joanna.

[Marek Marczykowski]

As a follback option you can setup dual boot environment (manually, but
doable). Don't forget about Anti Evil Maid to protect /boot against the other
system.

--
Best Regards / Pozdrawiam,
Marek Marczykowski
Invisible Things Lab

[bradbury9]

Joanna, Marek, thanks for the info, greatly appreciated.

I will try Joanna advice and, if failed, Marek's one. Will have two gaming HVM

One for a fedora17 (or ubuntu) HVM. Steam has Fedora 17 and ubuntu packages/repo (with debian or mint some tweaks must be done to the deb package, wrong dependencies on the Steam deb package) so with the correct packages should work fine.
The other one for HVM (windows) using qvm-pci.

My plan is to get the hardware in about a couple of months, will let you know if works fine, emailing to update HCL.

Many games try to get fullscreen, would it cause problems with the HVM?

[Marek Marczykowski]

On 23.01.2013 17:41, bradbury9 wrote:
> Joanna, Marek, thanks for the info, greatly appreciated.
>
> I will try Joanna advice and, if failed, Marek's one. Will have two gaming
> HVM
>
> One for a fedora17 (or ubuntu) HVM. Steam has Fedora 17 and ubuntu
> packages/repo (with debian or mint some tweaks must be done to the deb
> package, wrong dependencies on the Steam deb package) so with the correct
> packages should work fine.
> The other one for HVM (windows) using qvm-pci.
>
> My plan is to get the hardware in about a couple of months, will let you
> know if works fine, emailing to update HCL.
>
> Many games try to get fullscreen, would it cause problems with the HVM?

The fullscreen inside of HVM will fill whatever it get as screen - VM window
in case of emulated GPU, real fullscreen in case of real GPU.

[Alex Dubois]

Hi Joanna,

I thought you said the dedicated GPU, if NVidia could act as an attack vector?

If not I'll give it a go too...

Alex

[Joanna Rutkowska]

> On 23 Jan 2013, at 16:49, Marek Marczykowski <marm...@invisiblethingslab.com> wrote:
>
>> On 23.01.2013 17:41, bradbury9 wrote:
>>> Joanna, Marek, thanks for the info, greatly appreciated.
>>>
>>> I will try Joanna advice and, if failed, Marek's one. Will have two gaming
>>> HVM
>>>
>>> One for a fedora17 (or ubuntu) HVM. Steam has Fedora 17 and ubuntu
>>> packages/repo (with debian or mint some tweaks must be done to the deb
>>> package, wrong dependencies on the Steam deb package) so with the correct
>>> packages should work fine.
>>> The other one for HVM (windows) using qvm-pci.
>>>
>>> My plan is to get the hardware in about a couple of months, will let you
>>> know if works fine, emailing to update HCL.
>>>
>>> Many games try to get fullscreen, would it cause problems with the HVM?
>>
>> The fullscreen inside of HVM will fill whatever it get as screen - VM window
>> in case of emulated GPU, real fullscreen in case of real GPU.
>>

On 01/24/13 09:54, Alex Dubois wrote:> Hi Joanna,

>
> I thought you said the dedicated GPU, if NVidia could act as an attack
vector?
>
> If not I'll give it a go too...
>
> Alex
>

Well, sure, passing such complex device as a GPU to untrusted domain
does have some risks -- e.g. modern GPUs (some at least) do have their
own reflashable firmware and we never cannot be sure whether the
untrusted VM won't find a way to modify it (in fact we have confirmed
this in practice for some GPUs we tested). Then, the compromised
firmware, could theoretically attack the platform boot sequence, and I
don't think neither SRTM nor even Intel TXT could stop it then.

In practice I've never seen a successful attack of this kind, mostly
because GPU's internals are not documented for most (all?) GPUs, so even
if an attacker found a way to reflash the GPU's firmware, it would be
hard for them to actually write some sensible one, knowing nothing about
the underlying architecture.

Theoretically the same could happen when one passes other PCIe devices,
such as network cards, or USB controllers. On the other hand, it seems
much less likely to find a way to reflash firmware on such "simple*
devices -- at least I've never seen this happening in practice on modern
hardware (e.g. on integrated devices in laptops).

Here we talk about a situation when we pass GPU to one VM and leave it
there (this, of course, assumes we have two or more monitors also),
specifically we don't switch it constantly between Dom0 and some
untrusted VM. In this case (which is also hard to support without
special additional code in the hypervisor) the attack surface would
likely be much larger, I think.

My personal advice -- unless you are a Flame or Red October admin, or
otherwise high-profile target, you should probably be safe trying 2nd
GPU pass-thorugh to your gaming/personal HVM ;)

joanna.

[Alex Dubois]

OK I'll give it a go then...

Alex

[bradbury9]

Please, when you do it, please tell me about the results or send the info to the mailing list. I am considering in buiding a i7 with an expensive gpu to try qubes on it and if it does not work i will modify the build.

[Alex Dubois]

Ok but very busy. Planed for test in 2 weeks...

Alex

--
 
 

[bradbury9]

Just tried passing GPU with "qvm-pci -a"... It turns out there is some problem passing GPU via qvm-pci. Looks like Xen does not like it very much when it comes with GPU's.

$qvm-start gamingLinux

libxl: error: libxl_pci.c:767:libxl_device_pci_reset The kernel doesn't support reset from sysfs for PCI device 0000:01:00.0
libxl: error: libxl_pci.c:726:do_pci_add xc_assign_device failed
libxl: error: libxl_pci.c:477:libxl__wait_for_device_model Device Model not ready
libxl: error: libxl_pci.c:641:libxl__pci_notify_device_model qemu refused to add device: 0000:01:00.0

The GPU is a Geforce GTX 680. Is there any qvm-pci option or can the HVM config files be edited to make Xen allow those commands?

El jueves, 24 de enero de 2013 18:01:59 UTC+1, Alex Dubois escribió:

[bradbury9]

El viernes, 15 de febrero de 2013 20:16:30 UTC+1, bradbury9 escribió:

Just tried passing GPU with "qvm-pci -a"... It turns out there is some problem passing GPU via qvm-pci. Looks like Xen does not like it very much when it comes with GPU's.

$qvm-start gamingLinux

libxl: error: libxl_pci.c:767:libxl_device_pci_reset The kernel doesn't support reset from sysfs for PCI device 0000:01:00.0
libxl: error: libxl_pci.c:726:do_pci_add xc_assign_device failed
libxl: error: libxl_pci.c:477:libxl__wait_for_device_model Device Model not ready
libxl: error: libxl_pci.c:641:libxl__pci_notify_device_model qemu refused to add device: 0000:01:00.0

The GPU is a Geforce GTX 680. Is there any qvm-pci option or can the HVM config files be edited to make Xen allow those commands?

I was looking in Xen PCI passthrough wiki[1] and I realized that my GPU does not seems to not support 'FL Reset', dunno what the hell it is, but it seems that is the way Xen implements the reset of the GPU, although it is not the only way (if vmware sees device does not support FLR it tries 2 or 3 other ways to reset it). Later I found some info there they recommend Ati cards and discourage Nvidia :-( [2], a list of Ati and Nvidia out-of-the-box working GPU's[3] and some Xen patches[2] that a guy created to make work a unsupported Ati.

[1]: http://wiki.xen.org/wiki/Xen_PCI_Passthrough#How_can_I_check_if_PCI_device_supports_FLR_.28Function_Level_Reset.29_.3F
[2]: http://wiki.xen.org/wiki/SecondaryGPUPassthrough
[3]: http://wiki.xen.org/wiki/XenVGAPassthroughTestedAdapters
[4]: http://old-list-archives.xen.org/archives/html/xen-devel/2010-05/msg00441.html

Hope it helps others, as long as it will make me dualboot :-(

Any hint on how to dualboot with Qubes? Guess that the steps are:
1- Install Qubes leaving unpartitioned space
2- Install windows in the free space
3- Boot with Qubes installer and reinstall the grub. Dunno how to do this.

[Cosmic Charade]

I hope I am not rudely jumping in, I'm very new here (I just discovered Qubes!)

May I ask if the Nvidia binary driver working yet?  I'd also like to install Windows 8 and give that a Nvidia GTX GPU.  My motherboard or CPU also has built in Intel GPU.  What about for the Hypervisor and guest OS's overall?

How would it go having Nvidia binary driver installed in Linux, a guest OS and Windows OS?  Man my head hurts..

I didn't want to start a new thread in case I should have used an existing thread instead.

Thanks.. you guys all rock..

[gorka -]

Forwarding to the list ;-)

---------- Forwarded message ----------
From: gorka - <ray.br...@gmail.com>
Date: 2013/3/3
Subject: Re: GPU passing to HVM (was: Re: [qubes-devel] Re: Question about windows HVM)
To: Cosmic Charade <cosmic...@gmail.com>

If you try with a a NVidia you have three choices:

a) Use one of the cards that the Xen guys have tested and discovered to work [1]. There are some NVidia cards in that list, but there are some of the Quadro branch (6000, 5000, 4000, 2000) and not the GTX branch. Ati cards are mostly supported.

b) There is some guy that got a GTX working in a recent windows guest, I think it was using Xen 4.1 and a windows 7 guest. He implemented into Xen the passthough patches in [2] and did some specific configuration to avoid the FLR calls. I read all the steps but didnt bookmark the link :-(. I just searched again. I think this is the link [3]

c) Using Xen 4.2 there is some weird steps that I haven tested and to be honest I fail to fully undestand, extracting the GPU EPPROM and patching Xen [4]. Be warned that Qubes uses 4.1, not 4.1 so b) option would apply.

Xen does use a only something called FLR to reset hardware and most NVidia cards do not have that FLR capability (dunno if any of them have it). My GTX 680 does not have it. There is some Xen configuration that can be made to workaround this issue. Thought I had posted it, my bad. Other virtualization alternatives, i think it was vmware, try FLR and, if device is not capable, they fallback to two other alternatives.

Hope this info helps.

[1] http://wiki.xen.org/wiki/XenVGAPassthroughTestedAdapters
[2] http://old-list-archives.xen.org/archives/html/xen-devel/2010-05/msg00441.html

[3] http://en.usenet.digipedia.org/thread/11820/45042/
[4] http://wiki.xen.org/mediawiki/images/0/0a/Xen_VGA_Passthrough_-_Version_2.1.pdf

I am not a linux programmer, so cannot try to patch Qubes with [2] patches withouth messing it. Besides maybe the secondary GPU passthougthrough is not the the desired way to get GPU acceleration, am i wrong Joanna, Marek?

2013/3/3 Cosmic Charade <cosmic...@gmail.com>

[Cosmic Charade]

If I am reading this correctly, I have to pass through graphics from Windows to Xen (which is what I was thinking before I re-read this so maybe it now makes sense).

Ideally, there would be some driver I could just install in Windows that handles all that.

What about the hypervisor itself, doesn't that need an Nvidia hardware level driver?  At the moment it looks like the VM's are all software rendered, I'm not sure how I'd check though.

[bradbury9]

Please, correct me if my guess is wrong.

Qubes: Xen is installed under linux. Runs windows VM
What you want: Xen is installed under _windows_. Runs windows VM

Is that correct? In that case the info you may find in this group to passthrough a secondary GPU to a windows HVM may be mostly useless. Some of the steps required (Xen patching, loading specific _linux_ kernel modules) are linux specific.

In my opinion, something similar would be needed if Xen is installed within windows, specially the loading modules (windows nvidia drivers) part, but I am not an expert in Xen. I would suggest you could find some help in official Xen wiki and devel mailing list if trying to do it in a Windows -> Windows passthrough.

[Joanna Rutkowska]

On 03/04/13 11:42, Cosmic Charade wrote:
> If I am reading this correctly, I have to pass through graphics from
> Windows to Xen (which is what I was thinking before I re-read this so maybe
> it now makes sense).
>
> Ideally, there would be some driver I could just install in Windows that
> handles all that.
>

Yes, ideally the driver from nvidia.com.

> What about the hypervisor itself, doesn't that need an Nvidia hardware
> level driver?

The hypervisor needs to know nothing about the specifics of the device
you passthrough.

> At the moment it looks like the VM's are all software
> rendered, I'm not sure how I'd check though.
>

I have no idea what you mean by "software rendered" in this context.

joanna.

>> 2013/3/3 Cosmic Charade <cosmic...@gmail.com <javascript:>>

[Joanna Rutkowska]

On 03/04/13 15:38, bradbury9 wrote:
> Please, correct me if my guess is wrong.
>
> Qubes: Xen is installed under linux. Runs windows VM

Correcting, as requested. Xen cannot be installed "under Linux" -- after
all it's a _baremetal_ hypervisor, right? Ignoring the rest of the post.

joanna.

[Cosmic Charade]

ah yeah, Xen is not installed 'under' anything, it 'is' the very thing that other things are installed 'under' - hence the term 'hypervisor'.

So if I install the binary Nvidia driver within the Windows 8 environment, won't this break something? Or may it in fact work?  I'm not so concerned about something as ultra complex as games, which I can boot in to a native Windows 8 for, I just want the graphics card to support at least desktop compositing and playing videos and whatever.

As for 'software rendering' - I mean in the days of yore in Linux when hardware graphics often didn't work for lack of a driver, so all the rendering was done in software or by the CPU instead of the GPU and it showed - as in windows not being smooth and just looking like the CPU rather than GPU was doing all the graphics work.  Which is not what CPU's are for.  And I don't want to spend my days living in a text terminal if I can help it (as useful as I find a terminal, but within a GUI environment thank you!)

So if Xen doesn't need a graphics driver, where would I install it?  Can I install the Nvidia graphics driver under the Fedora VM and Windows HVM?  Won't those two VM's then clash or something?  Thats why I wondered if the hypervisor had to 'mangle' all the graphics stuff together from all the various VM's.

And on the Wiki page, it says Nvidia driver not compatible with Xen - is this true?

[Joanna Rutkowska]

On 03/04/13 21:27, Cosmic Charade wrote:
> ah yeah, Xen is not installed 'under' anything, it 'is' the very thing that
> other things are installed 'under' - hence the term 'hypervisor'.
>
> So if I install the binary Nvidia driver within the Windows 8 environment,
> won't this break something? Or may it in fact work? I'm not so concerned
> about something as ultra complex as games, which I can boot in to a native
> Windows 8 for, I just want the graphics card to support at least desktop
> compositing and playing videos and whatever.
>
> As for 'software rendering' - I mean in the days of yore in Linux when
> hardware graphics often didn't work for lack of a driver, so all the
> rendering was done in software or by the CPU instead of the GPU and it
> showed - as in windows not being smooth and just looking like the CPU
> rather than GPU was doing all the graphics work. Which is not what CPU's
> are for. And I don't want to spend my days living in a text terminal if I
> can help it (as useful as I find a terminal, but within a GUI environment
> thank you!)
>
> So if Xen doesn't need a graphics driver, where would I install it?

In your Windows HVM.
j.

[Cosmic Charade]

OK this is my lack of technical understanding coming through.

So the Xen hypervisor does *not* require a graphics driver, but each VM does?  What would happen if I installed the Linux Nvidia binary driver in the Fedora default VM's, and the binary Nvidia driver in a Windows 8 VM?  Wouldn't they clash or something?  I don't want to play games (I'll use a bare metal Windows for that), but I may want to watch some basic / streaming media or full screen video (not DRM protected blu-ray's - but possibly .mkv or other video files).

[Radoslaw Szkodzinski]

On Thu, Mar 7, 2013 at 5:44 AM, Cosmic Charade <cosmic...@gmail.com> wrote:
> OK this is my lack of technical understanding coming through.
>
> So the Xen hypervisor does *not* require a graphics driver, but each VM
> does? What would happen if I installed the Linux Nvidia binary driver in
> the Fedora default VM's, and the binary Nvidia driver in a Windows 8 VM?
> Wouldn't they clash or something? I don't want to play games (I'll use a
> bare metal Windows for that), but I may want to watch some basic / streaming
> media or full screen video (not DRM protected blu-ray's - but possibly .mkv
> or other video files).

You can redirect the GPU only to one virtual machine at a time. The
real question is whether the driver correctly resets the card, so you
can attach it again.
For example Catalyst drivers did not (10.12 or so - first version with
Radeon 7950 support) - but xm's old way of reset worked well. Perhaps
someone should patch that into xl as well for cards w/o FLR like that
one.

Theoretically Qubes GUId may be just about fast enough for full screen
video, if your CPU is fast enough to decode it in software with some
remaining power, as the GUI protocol is relatively CPU intensive.
It is too slow for fullscreen Flash though - that thing has very slow
software decoding and/or scaling.
(CPU here: Xeon E3 1275)

--
Radosław Szkodziński

[Cosmic Charade]

On Thursday, 7 March 2013 17:50:10 UTC+11, Radosław Szkodziński wrote:

You can redirect the GPU only to one virtual machine at a time. The
real question is whether the driver correctly resets the card, so you
can attach it again.

Works for me..  So I just install the binary drivers in to each VM environment and I'm good to go.

 

For example Catalyst drivers did not (10.12 or so - first version with
Radeon 7950 support) - but xm's old way of reset worked well. Perhaps
someone should patch that into xl as well for cards w/o FLR like that
one.

And here's the catch :-)  Only one way to find out I suppose.

 

Theoretically Qubes GUId may be just about fast enough for full screen
video, if your CPU is fast enough to decode it in software with some
remaining power, as the GUI protocol is relatively CPU intensive.

Qubes GUID?  You mean the X server and the like in the Fedora VM's or by the hypervisor itself?  Ideally software decoding would be shunted to hardware wherever possible as most PC's have this sort of hardware built in now (decode acceleration), but even so the binary driver run everything just fine I would have thought.

 

It is too slow for fullscreen Flash though - that thing has very slow
software decoding and/or scaling.
(CPU here: Xeon E3 1275)

Should be fine with binary drivers, I'll find out.

 

--
Radosław Szkodziński

[bradbury9]

El jueves, 7 de marzo de 2013 09:36:53 UTC+1, Cosmic Charade escribió:

On Thursday, 7 March 2013 17:50:10 UTC+11, Radosław Szkodziński wrote:

You can redirect the GPU only to one virtual machine at a time. The
real question is whether the driver correctly resets the card, so you
can attach it again.

Works for me..  So I just install the binary drivers in to each VM environment and I'm good to go.

 

For example Catalyst drivers did not (10.12 or so - first version with
Radeon 7950 support) - but xm's old way of reset worked well. Perhaps
someone should patch that into xl as well for cards w/o FLR like that
one.

And here's the catch :-)  Only one way to find out I suppose.

That's the main problem with most NVidia cards.
 

[Cosmic Charade]

That blows...

Is there any way to compensate for the lack of a reset command in NVidia cards?

I'm fine with hardware lock to each VM as they are used although I'm not sure how this would work with windows from different VMs displaying simultaneously.

[bradbury9]

On the links I provided there was a guy that workarounded that problem configuring the HVM to not to reset the device, but I share Radoslaw opinion. It would be wiser to patch the code. Is vmware code publicy accesible? they do two different alternative ways to reset if FLR is not available.

[Radoslaw Szkodzinski]

On Fri, Mar 8, 2013 at 8:49 AM, bradbury9 <ray.br...@gmail.com> wrote:
> On the links I provided there was a guy that workarounded that problem
> configuring the HVM to not to reset the device, but I share Radoslaw
> opinion. It would be wiser to patch the code. Is vmware code publicy
> accesible? they do two different alternative ways to reset if FLR is not
> available.

Xend has the right reset code, tries: FLR, then P-states warm reset,
then P-states power off, and if all fails, PCI bus reset.
This is obviously available.

--
Radosław Szkodziński

[Cosmic Charade]

PCI bus reset sounds a bit harsh? Could that damage hardware in any way?

--
You received this message because you are subscribed to a topic in the Google Groups "qubes-devel" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/qubes-devel/MfHy2jmXhXM/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to qubes-devel...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Radoslaw Szkodzinski]

On Fri, Mar 8, 2013 at 9:45 PM, Cosmic Charade <cosmic...@gmail.com> wrote:
> PCI bus reset sounds a bit harsh? Could that damage hardware in any way?

No, at worst it will result in a hardware hang with associated file
system damage, if any at all.
Perhaps even necessitating a full power cycle.

--
Radosław Szkodziński

[Cosmic Charade]

So it is a harsh method but could work then... may need a way to soft restart PC if it hangs then

[kod.c...@gmail.com]

Xend has the right reset code, tries: FLR, then P-states warm reset,
then P-states power off, and if all fails, PCI bus reset.
This is obviously available.

--
Radosław Szkodziński

I agree, this is most probably available unless something in kernel is off, or if not using xend, because i think with xl things got broken. Maybe xl will get fixed in future, but doubtly, and for the time being is probably better to have xend.

IMHO, the security issue of VGA passthrough might have other perspective. If there is something there smart enough to encode itself in the video card, it will boot by simple power on, and has own resources and physical access regardless if its used as device or not. Let your imagination wild, write your own microcode etc. I think this is why the idea is so attractive. So the security might be already compromised by the video card just *being there*. If it is passed throguh, actually might just help keeping connectivity busy, might force ware into hiding mode. So dunno how much this is right or wrong, but *my os accessing the video card* might just not be same with *video card accessing me*. At the very least i am inclined to think like so.

Hard virtualization is coming and imho it will bring many changes, weather we like it or not. Ex many OS-es will become bundled apps. Degraded from os to apps status. Want some programs for say electronics, fire up fedora-electronic-lab in a vm, and you got it all, but thats not an os anymore, its a bundle of apps that just dont bother with incompatibilities. Schools use spins that are tailored for certain topics. Are you a game maker, make your own os to be your game engine. Ultimate cross-platform. Not there yet, but coming. I think this aspect and what it means is largely underestimated. If someone today would officially support vga passthrough out of box, it would gain an immense momentum right now. Or will be bought out by another co, probably to delay things and help ms's hyper-v. But doing the same thing 2-3 years from now when everyone will have the feature, it wont mean anything then. Again this is just my opinion.

[Radoslaw Szkodzinski]

That old thread and I got pinged.

Of course, it has issues like any hardware passing. If the hardware
has programmable firmware that survives reboots/resets, then malware
could encode into it and exploit the drivers.
Therefore you should not attach the device to any more secure domain
afterwards; passing it across domains of the same security degree
should be fine though.
Dom0 does not have to actually run the driver for this device though,
but it is an avenue for an attack on the EFI code. Hard to pull off
though.

Hardware virtualization for GPUs is still some ways off, look at how
long it took for CPUs to handle properly.

R.

[kod.c...@gmail.com]

I like that. It makes total sense to me to have a secondary video cards locked down in least secure area. If i have a win vm with vga on it, i will certainly play alot of games and each of them will be totally insecure :) The whole point of having it like that is coz the low chances that malware is able to jump the virt jail, jump across os-es, or else. If we do have a malware at a difficulty degree that is able to encode itself into the bios, then probably it is at least equally capable to do the other things, or done it already.

Again, with xend this should be already possible for Qubes os, i mean with a secondary video card. Can we get some sort of confirmation if it is or not possible - and i dont mean supported, just possible atm.
Does beta3 still use xend api, and can this be played with, any caveats for this under Qubes os?

[David Schissler]

Very true.  Who could have thought that GNU/Hurd would would be usable while being virtualized on top of a hypervisor with a GNU/Linux graphical front end.  Maybe funnier things have happened?
 

[David Schissler]

A British company is selling upgraded Thinkpad X60 machines (Core 2 64 bit) with the BIOS replaced by coreboot.
http://shop.gluglug.org.uk/product/ibm-lenovo-thinkpad-x60-coreboot/

[france...@gmail.com]

So... has it been patched? I have a Geforce 740m, in addition to the one integrated in the CPU (i7 Haswell), and I run Beta 3. If I create a HVM and select the GPU to be passed through in the settings, should the guest work with the video card as if it was installed on bare metal? Or will strange things happen?

[Markus F]

Has anyone managed to completely pass any graphics card to a HVM in qubes yet? Or has this thread firmly settled on not-possible-right-now?

— 

 

I'm building a PC and would like to use Qubes. Since this means getting components that play nice with VT-d anyway, it seems a shame not to at least try GPU passthrough rather than perpetual system swapping. To this end I am considering getting an intel processor with onboard graphics for Qubes, and an ATI card (R9 280X) to passthrough to a Win8 HVM (with another monitor connection to the card). 

Right now, I have zero experience with qubes (this will be remedied!), but reasons I think this isn't just a mad wish:

• Xen wiki about Xen 4.1.1: "Passing thru AMD/ATI Radeon/FirePro/FireGL adapters as secondary to the VM should work out-of-the-box (you need latest ATI gfx drivers in the VM). Secondary means the Xen Qemu-dm virtual Cirrus adapter is the primary where you see the VM BIOS etc when powering on the VM, and the passthru adapter is secondary, so you can enable/use it after the OS in the VM has started and you've installed drivers for the adapter."
• A xen user's success story / tutorial with a "7970/R9 280X" with Ubuntu and Windows 7. 
• Everyone reporting a failures seems to be talking about nvidia GPUs, which are known to misbehave under xen for a number of reasons.

Does that leave any reason why these settings shouldn't work in qubes? Of course, qubes isn't just xen, so I imagine the differences are where the trouble lies, but I don’t yet know where all the differences lie.

Security-wise, again I understand that I understand basically nothing, but from Joanna’s reply above, it seems to me that there isn’t too much danger as long as I never assign the GPU to any higher security areas.