PCI passthrough

[John Mitchell]

Is anyone gaming in a qube using PCI passthrough? I am thinking about building a new system and I am pondering if qubes is ready. I know this works very well, almost native speed with Debian. I would prefer using qubes however.

[Joe]

On 11/06/2018 04:47 PM, John Mitchell wrote:
> Is anyone gaming in a qube using PCI passthrough? I am thinking about building a new system and I am pondering if qubes is ready. I know this works very well, almost native speed with Debian. I would prefer using qubes however.
>

#1 hit on google for [qubes pci passthrough gaming]:

https://www.reddit.com/r/Qubes/comments/66wk4q/gpu_passthrough/

TL;DR: Yes, but from a security point of view it's not a good idea.

[John Mitchell]

Thank you for the reply.

I sense the qubes team isn't really interested and I would be better off using Debian for my primary OS. I've had this vision since the 90's of booting a qubes like OS and then running various OSes in VMs however this is all useless without GPU passthrough. Security is great but not when it gets in the way of being useful. I need useful or I have to buy two separate computers systems. I believe the risks are acceptable using PCI passthrough. Those that need more security don't have to use PCI passthrough. One less qubes user saying how great it is.

I wish the best for qubes and the team.

[Achim Patzner]

Am Mittwoch, den 07.11.2018, 13:17 -0800 schrieb John Mitchell:
> > TL;DR: Yes, but from a security point of view it's not a good idea.
>

> I sense the qubes team isn't really interested and I would be better off using Debian for my primary OS.

> I've had this vision since the 90's of booting a qubes like OS and then running various OSes in VMs however this is all useless
> without GPU passthrough.

Well, Qubes is not exactly a clone of SteamOS and definitely not a
replacement for IBM's LPAR.

> Security is great but not when it gets in the way of being useful.

From my point of view that's plain wrong. It was already wrong when a
sweating Balmer was shouting at us in Redmont: "Is it security the
customer wants? No! He doesn't! He wants easy of use!". Spitting at the
people in the first row...

To paraphrase Benjamin Franklin: "They that can give up essential
security to obtain a little playing computer games deserve neither
security nor computer games."

> I need useful or I have to buy two separate computers systems. I believe the risks are acceptable using PCI passthrough.

You are welcome to use a systm that fits your needs

> Those that need more security don't have to use PCI passthrough.

And this is exactly the place where such creatures dwell. The first few
sentences on the Qubes home page might have tld you so.

> One less qubes user saying how great it is.

Wow. Aren't we a bit passive-aggressive here?


Achim

[John Mitchell]

My last reply. Since I will not feed the anger.

Rather than attack the messenger maybe you should stop and consider what I wrote. I am not a fan of Stevie B. or M$. And you were not helpful in my opinion.

If you really want security then you should power down the system and bury it where only you can find it and then maybe it would be secure but I doubt it.

;)

Cheers!

John

[js...@bitmessage.ch]

John Mitchell:

Hi,

Let's not fight. Can't we all get along?

Anyways, my understanding is that gpu passthrough in qubes is possible
but very challenging (use an amd card not nvidia). I've never tried to
get it working tho.

To address the security vs convenience discussion, it's always a
tradeoff. It's just a matter of deciding how much security you need and
how much inconvenience you can put up with. Qubes users are going to
fall closer to the security end of the scale, but there's a lot of
variation among qubes users too. Some need maximum security even if that
means a high level of inconvenience and doing without nifty features,
and some really want the nifty features and don't have time to
troubleshoot a lot of problems and so are willing to accept a somewhat
lower level of security. Both are ok.

Anyways, if you really need gpu passthrough, i'd try to get it working
in qubes if possible, if you have a lot of time for troubleshooting at
least. Using gpu passthrough in qubes would present a security risk
(compared to qubes with no gpu passthrough), but it would still be a lot
better from a security perspective than using debian.

Also maybe qubes-users list would be a better place to discuss this? Gpu
passthrough is a pretty low priority for the qubes devs for obvious reasons.

--
Jackie

[ser...@da.matta.nom.br]

Dear John, I am interested. Not to play games but to use windows and VR with Qubes. I am not a developer but I will try to install docker and see my Qubes windows inside windows vm too.
Please share your work.
Thank you.

[John Mitchell]

On Thursday, November 8, 2018 at 2:20:04 AM UTC+1, js...@bitmessage.ch wrote:
<snip>

>
> Also maybe qubes-users list would be a better place to discuss this? Gpu
> passthrough is a pretty low priority for the qubes devs for obvious reasons.
>
> --
> Jackie

Hi Jackie,

Thank you for the nice reply.

I will check out the qubes-users list.

I've been following qubes for a long time, since the beginning I believe. Qubes is my dream after all. I've heard all of the security arguments over the years and you are correct there is always a trade off between usability and security. It ranges from almost no security (M$) to burying the computer in the ground. :)

I would respectfully suggest the developers consider supporting PCI-passthrough. It isn't just GPUs that are useful for PCI-passthrough, passing the SATA and USB controllers can also be very useful. Passing the PCI device can eliminate much of the OS overhead. When enabling or using this feature a warning could be issued to the qubes admin of the security risk. I assume the developers and team want people using their work. By including this as a feature qubes will be used on more systems. The more systems qubes runs on the more support qubes will receive from the community. I see this as a win win for qubes and the community.

In the past I had not the time however If the team is interested I am willing to offer my support for PCI-passthrough. I could help filter PCI-passthrough support between users and developers or even other ways.

Based on the last two replies I will likely try qubes with PCI-passthrough. However I am leery of future operability since this isn't currently supported or encouraged. So I am having trouble making a leap in this direction.

John

[Zrubi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 11/8/18 10:01 AM, John Mitchell wrote:

> I've been following qubes for a long time, since the beginning I
> believe.

> I would respectfully suggest the developers consider supporting
> PCI-passthrough.

I should just say:
RTFM.

But let me share some details:

Qubes is supporting PCI-passthrough from the very first release.
That is how the sys-net using your network devices.

Later releases extended this for USB buses -> now the default install
creating a sys-usb Qube for you.

What is not working (out of the box) is passing VGA devices.
Because this is a different beast.
Read the docs, and the previous discussions (on qubes-users) about
this if you really interested...

And honestly, I believe if you would ever try Qubes OS, you would not
start this thread at all.

Peace.
- --
Zrubi
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEmAe1Y2qfQjTIsHwdVjGlenYHFQ0FAlvkAK4ACgkQVjGlenYH
FQ2yvw//f0dHxwtZk4UScQC455V1/ThjBIEoQZI8DZL/vbbH11kVHmGsKjDJdBBH
Yyl4L4Xt4L7qxHoCE3XTogwhgibhFFlolEGkUNnz81SgEYMRYJjzMFGYcRe8AAnn
tjTOUQY2DnlTyCik3gb5RFafGS89keEzQkytRmRcZka25AHMh32vvqTfBM8SwrWI
5p7Dbklh0Yt56fW8mo7xdv8a4rAoqRc2bXKlgS6ANOb7tASsBKbOvmvRytPyqeH0
RLMuxOUHg70dDyAROpgNKEzVyYLTUkRQ9J3/Cl/J47wnwnLKHIIL/WDT1Nvvyf5E
CmLBrnQbn5oPUdMHwaBzhN8dNSiA4Mq4fPC9mWGlykVYrKph6TO9pQtK+oBsbswC
s5fRWSi1G8gEiV7o/+E+Lz5jd9WDLxZ3+r7nm4o9QoY71NVR3/farV1hw4C+PJFs
oo84VbQJP9qUeAMIwUwRlWE3xCbSrwfIJZSx+2vR+i8ElxWGaThtO1crbV/CrUtr
7KFSZEFk/8vtvqfF/gTVUTrD31HLopMOiY9jDUEg6c9Y1+cAEVCkGDqB/kSHSurp
Jm4NanisOJLGEcS/BGHFvyUqTPFrijFqtprzFkwuOlIjE3EeN7/g8WMXzvicUsut
KE61KZc8YMp4m8imXc9vajS7qoaPf+b9NQFefUrPtzGgCcwCH2g=
=6tcd
-----END PGP SIGNATURE-----

[John Mitchell]

On Thursday, November 8, 2018 at 10:24:13 AM UTC+1, Laszlo Zrubecz wrote:
<snip>

> I should just say:
> RTFM.
>
> But let me share some details:
>
> Qubes is supporting PCI-passthrough from the very first release.
> That is how the sys-net using your network devices.
>
> Later releases extended this for USB buses -> now the default install
> creating a sys-usb Qube for you.
>
> What is not working (out of the box) is passing VGA devices.
> Because this is a different beast.
> Read the docs, and the previous discussions (on qubes-users) about
> this if you really interested...
>
> And honestly, I believe if you would ever try Qubes OS, you would not
> start this thread at all.
>
> Peace.
> - --
> Zrubi

<snip>

So if I understand correctly, PCI device passthrough is supported but not GPU because it can be hacked and compromise the host?

While more difficult or perhaps not mature yet, well maybe not, other PCI devices (USB, SATA drives, etc.) can also be hacked.

So it appears security isn't the problem so it must be complexity although users are getting it working because zen supports it.

I am sure I am not the only one that would like GPU passthrough working without all of the headaches.

No more suggestions or discussions from me. I just asked the question because I wanted to see if this community had changed. I am going back to lurking, sorry for the bother.

Blessings

John

[eh...@posteo.net]

This windows-gaming passthrough thread isn't isolated to the Qubes
mailing list, other OS projects have seen the same manipulative
argumentation.

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Thu, Nov 08, 2018 at 01:52:37AM -0800, John Mitchell wrote:
> On Thursday, November 8, 2018 at 10:24:13 AM UTC+1, Laszlo Zrubecz wrote:
> <snip>
>
> > I should just say:
> > RTFM.
> >
> > But let me share some details:
> >
> > Qubes is supporting PCI-passthrough from the very first release.
> > That is how the sys-net using your network devices.
> >
> > Later releases extended this for USB buses -> now the default install
> > creating a sys-usb Qube for you.
> >
> > What is not working (out of the box) is passing VGA devices.
> > Because this is a different beast.
> > Read the docs, and the previous discussions (on qubes-users) about
> > this if you really interested...
> >
> > And honestly, I believe if you would ever try Qubes OS, you would not
> > start this thread at all.
> >
> > Peace.
> > - --
> > Zrubi
>
> <snip>
>
> So if I understand correctly, PCI device passthrough is supported but not GPU because it can be hacked and compromise the host?
>
> While more difficult or perhaps not mature yet, well maybe not, other PCI devices (USB, SATA drives, etc.) can also be hacked.
>
> So it appears security isn't the problem so it must be complexity although users are getting it working because zen supports it.

Yes, the main problem with GPU passthrough is complexity - those devices
abuse PCI specification in so many ways you wouldn't believe... There
are some workarounds, but most require qemu running in dom0, which is a
security issue.

There is also security aspect of GPU passthough in general, if you want
to share it between VMs in any way (for example switch from one VM to
another). Mostly because of GPU complexity and all the state it can
keep (including loaded firmware). Solving this require finding reliable
way to clear all its state.

> I am sure I am not the only one that would like GPU passthrough working without all of the headaches.
>
> No more suggestions or discussions from me. I just asked the question because I wanted to see if this community had changed. I am going back to lurking, sorry for the bother.
>
> Blessings
>
> John
>

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlvkFH0ACgkQ24/THMrX
1yx3FAf/ZkW/NRQwiy/nx24AkqxvWnxO6S7VKISqzPcfBQ6Q8V6iojz1QtUCGZNG
UuuPDHa/+R/czdFtuSCUtGUZGgL6uNtDybwopyXSiRWa5C9fEDRIoN8gH8RtSngt
G2Gk826+SgR5p11JuDjJ5nU6TaKUexCciO+vF+s/ukUeGYKzGtB4EEe3RUmYkp/k
L7RspCX0xExSRxYDTiZ1BuTGpsigeXicH7WUAZ0ntZHWelCOHNYCMWaUAz5aR2qL
vF1Mc8alNgvpfhiIUHbmN+I/S3MmdpV+uiXfML9nfLMcRrsSLnCRLgO/456oGMku
A43FDzqP+/QQ/yTk2VR+4Dq1bD0csw==
=oJnH
-----END PGP SIGNATURE-----

[Achim Patzner]

Am Donnerstag, den 08.11.2018, 11:38 +0100 schrieb eh...@posteo.net:

This windows-gaming passthrough thread isn't isolated to the Qubes

mailing list, other OS projects have seen the same manipulative

argumentation.

Which was the reason for my (admittedly annoyed) reaction; even more considering the clearly stated goals of Qubes development.

I would of course like to have access to my unused CPU capacities as schedulable processor package so I could offload tasks there...

Achim

[js...@bitmessage.ch]

John Mitchell:

As others have said pci passthrough in general is supported, for network
devices, usb controllers, etc. sys-net and sys-usb have pci devices
assigned by default.

This doc page has a lot of information about it:

https://www.qubes-os.org/doc/assigning-devices/

--
Jackie

[Radoslaw Szkodzinski]

The main actual problem, considering you would never keep the passed
through GPU ever in dom0 (always in vfio-pci), is how to reset the
device.
There are known bugs in Vega and Polaris implementation of PCIe reset
so they do not reset right - and additionally some mainboards do not
reprogram PCIe configuration space for secondary bridges.
Typically the GPU is passed in as a secondary card - skipping the
whole VGA passthrough thing.
With older driver versions, you had to also specify a ROM file
(containing video rom dump), but latest ones do not require it as they
have a fallback interface to access AtomBIOS.

nVidia on the other hand strictly requires as much hiding of the VM as
possible unless you own a Quadro and always have to add the video ROM,
but if it's successful it just works.
Passing the GPU between VM instances requires belief that device reset
for such a complex device has no data leaks...

On top of that, you have the problem that some IOMMU implementations
do not reset devices fully either.
Passing the GPU between VM instances securely requires belief that
device reset for such a complex device has no data leaks...
If you will never remove the GPU from VM nor stop the VM using it,
this shouldn't be a problem - but ensuring that in Windows world is
pretty hard with those silly automatic updates.
GPU VM, always on, never reset, with some sort of a proxy could avoid
this issue. I think Looking Glass project has some reasonable software
that can be investigated for this.

R.

[John Mitchell]

Thank you for the informative reply.

It appears the Vega reset bug is related to the VM presenting the card as a legacy PCI device rather than a PCIe device.

Looking Glass appears to be Alpha stage.

Windows update can be disabled. :)

I'll continue to explore this topic.

[Radoslaw Szkodzinski]

AMD has said that Vega needs PSP reset issued before disabling IOMMU
otherwise its internal bus will be all sorts of messed up and
unavailable.
Alternatively you can quirk this device to not be reset and put in D3
at all, then it will be reset by the driver on next guest boot, but
that has some security implications.

I'm not entirely sure what is currently wrong with the IOMMU on my TR4
X399, but 4.17 works, while 4.18+ kernel is a total failure on reset
even with new AGESA which does attempt to rewrite PCIe option ROM.
I suspect this can fix it:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3c120143f584360a13614787e23ae2cdcb5e5ccd
If not I'll go bisecting.

Card is also messed up if passed through even after S3, also the above
is supsected. S3 actually fully resets the GPU otherwise as tested
when the GPU is booted by EFI, in which case you can use S3 to reset
it; but not if you IOMMU pass it somewhere. Likely by the same
TLB/IOVA handling bug - TLB/IOVA cannot be touched in S3 resume.
At least 4.20-rc got some real debugfs for AMD IOMMU which will help
finding out what's wrong.

> Looking Glass appears to be Alpha stage.

Yes, and it is not quite right way around - allows to show Windows
headless in Linux or Windows target. Mostly useful to not have a
monitor cable run to the GPU.
It seems to be mostly doing what Qubes driver is doing? Works well
enough if you want the VM visible in a window or fullscreen on another
GPU.
Perhaps even if the passed through GPU is a laptop secondary as it
needs no output mapping and thus neither framebuffer mapping nor
hardware output mux and vga switcheroo.

Another way would be to use Virgil 3D and write a virtual Windows
driver for it or extend the Qubes one. https://virgil3d.github.io/
Make sure to still put the GPU and vfio-virgl in a VM for any
security, scrape the GPU framebuffer from there and redisplay it
safely in host after improving Qubes framebuffer proxy to handle vsync
better.
That option would run the GPU code in Linux VM after proxying.
Relatively high potential for bugs and issues though as shader
implementation will likely have compatibility issues... Might be
harder to exploit as it's a sort of a proxy.

> Windows update can be disabled. :)

That is a terrible idea in a sea of bad ideas... Windows is buggy
enough already even with latest patches applied.
It's better to disable GPU reset instead if that's problematic - the
driver should handle it properly.

>
> I'll continue to explore this topic.

Long version short: good luck and get your low level hardware
debugging goggles on.

--
Radosław Szkodziński

[John Mitchell]

On Tuesday, November 13, 2018 at 5:21:22 PM UTC+1, Radosław Szkodziński wrote:

> On Tue, Nov 13, 2018 at 12:02 PM John Mitchell <snip> wrote:
> >
> > On Tuesday, November 13, 2018 at 5:01:06 AM UTC+1, Radosław Szkodziński wrote:
> > > On Thu, Nov 8, 2018 at 11:48 AM Marek Marczykowski-Górecki
> > > <marmarek@<snip>> wrote:
> > > >
> > > > -----BEGIN PGP SIGNED MESSAGE-----
> > > > Hash: SHA256
> > > >
> > > > On Thu, Nov 08, 2018 at 01:52:37AM -0800, John Mitchell wrote:
> > > > > On Thursday, November 8, 2018 at 10:24:13 AM UTC+1, Laszlo Zrubecz wrote:
> > > > > <snip>
> >

> > Thank you for the informative reply.
> >
> > It appears the Vega reset bug is related to the VM presenting the card as a legacy PCI device rather than a PCIe device.
>
> AMD has said that Vega needs PSP reset issued before disabling IOMMU
> otherwise its internal bus will be all sorts of messed up and
> unavailable.
> Alternatively you can quirk this device to not be reset and put in D3
> at all, then it will be reset by the driver on next guest boot, but
> that has some security implications.

I've discovered a way to reset the card inside of Windows during shutdown and startup. So I think I am good there. I admit I haven't been able to test this for myself.

> I'm not entirely sure what is currently wrong with the IOMMU on my TR4
> X399, but 4.17 works, while 4.18+ kernel is a total failure on reset
> even with new AGESA which does attempt to rewrite PCIe option ROM.
> I suspect this can fix it:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3c120143f584360a13614787e23ae2cdcb5e5ccd
> If not I'll go bisecting.
>
> Card is also messed up if passed through even after S3, also the above
> is supsected. S3 actually fully resets the GPU otherwise as tested
> when the GPU is booted by EFI, in which case you can use S3 to reset
> it; but not if you IOMMU pass it somewhere. Likely by the same
> TLB/IOVA handling bug - TLB/IOVA cannot be touched in S3 resume.
> At least 4.20-rc got some real debugfs for AMD IOMMU which will help
> finding out what's wrong.

This is certainly a work in progress.

> > Looking Glass appears to be Alpha stage.
>
> Yes, and it is not quite right way around - allows to show Windows
> headless in Linux or Windows target. Mostly useful to not have a
> monitor cable run to the GPU.
> It seems to be mostly doing what Qubes driver is doing? Works well
> enough if you want the VM visible in a window or fullscreen on another
> GPU.
> Perhaps even if the passed through GPU is a laptop secondary as it
> needs no output mapping and thus neither framebuffer mapping nor
> hardware output mux and vga switcheroo.
>
> Another way would be to use Virgil 3D and write a virtual Windows
> driver for it or extend the Qubes one. https://virgil3d.github.io/
> Make sure to still put the GPU and vfio-virgl in a VM for any
> security, scrape the GPU framebuffer from there and redisplay it
> safely in host after improving Qubes framebuffer proxy to handle vsync
> better.
> That option would run the GPU code in Linux VM after proxying.
> Relatively high potential for bugs and issues though as shader
> implementation will likely have compatibility issues... Might be
> harder to exploit as it's a sort of a proxy.

I hope somebody makes it work one day.

> > Windows update can be disabled. :)
>
> That is a terrible idea in a sea of bad ideas... Windows is buggy
> enough already even with latest patches applied.
> It's better to disable GPU reset instead if that's problematic - the
> driver should handle it properly.

I didn't mean to imply I would never update just update on my schedule not M$.

> > I'll continue to explore this topic.
>
> Long version short: good luck and get your low level hardware
> debugging goggles on.

All the best to the qubes team!

> --
> Radosław Szkodziński

Returning to lurking mode.

[Jean-Philippe Ouellet]

I would be very happy to help fund development in this area if anyone
qualified & serious is interested.

Regards,
Jean-Philippe

[Radoslaw Szkodzinski]

On Tue, Nov 13, 2018 at 8:23 PM John Mitchell <sonw...@gmail.com> wrote:
>
> On Tuesday, November 13, 2018 at 5:21:22 PM UTC+1, Radosław Szkodziński wrote:
> > On Tue, Nov 13, 2018 at 12:02 PM John Mitchell <snip> wrote:
> > >
> > > On Tuesday, November 13, 2018 at 5:01:06 AM UTC+1, Radosław Szkodziński wrote:
> > > > On Thu, Nov 8, 2018 at 11:48 AM Marek Marczykowski-Górecki
> > > > <marmarek@<snip>> wrote:
> > > > >
> > > > > -----BEGIN PGP SIGNED MESSAGE-----
> > > > > Hash: SHA256
> > > > >
> > > > > On Thu, Nov 08, 2018 at 01:52:37AM -0800, John Mitchell wrote:
> > > > > > On Thursday, November 8, 2018 at 10:24:13 AM UTC+1, Laszlo Zrubecz wrote:
> > > > > > <snip>
> > >
> > > Thank you for the informative reply.
> > >
> > > It appears the Vega reset bug is related to the VM presenting the card as a legacy PCI device rather than a PCIe device.
> >
> > AMD has said that Vega needs PSP reset issued before disabling IOMMU
> > otherwise its internal bus will be all sorts of messed up and
> > unavailable.
> > Alternatively you can quirk this device to not be reset and put in D3
> > at all, then it will be reset by the driver on next guest boot, but
> > that has some security implications.
>
> I've discovered a way to reset the card inside of Windows during shutdown and startup. So I think I am good there. I admit I haven't been able to test this for myself.

If you happen to have the information on how to make Windows 10 1803
or preferably 1809 and AMD drivers 18.xx to reset the GPU, please
share, since that'd be faster for me than patching vfio-pci with PSP
reset code.

I've tried various approaches including ejecting the device and they
have all failed. (The device is clearly enabled - the power lights
show it.) The dmesg shows IOVA errors as the GPU is trying to access
old invalid mapping and IOMMU prevents this.
With 17.xx drivers everything just works as the driver resets the GPU
on next boot with the flashing power light...

--
Radosław Szkodziński

[John Mitchell]

On Thursday, November 15, 2018 at 1:49:04 PM UTC+1, Radosław Szkodziński wrote:

Check this thread,

Linux Host, Windows Guest, GPU passthrough reinitialization fix

My understanding this only works with Windows Pro versions. What isn't working with this method are forced reboots from Windows Update. Easy to control with Windows 7 however Windows 10 will be a pain because of forced updates. It would be nice if this was incorporated into the VM startup and shutdown sequence, not sure if this is feasible since it requires Windows Device Console (Devcon.exe).

Also, I saw a thread somewhere where the graphic card shutdown sequence could be initiated via a different method inside of Windows that should work with Windows Updates. I didn't save that thread and it was untested when I read the thread.

I've also read that Linux kernel 4.16 has a fix for the graphic card reset problem. So maybe the problem is gone with Linux OSes using a new kernel? I am not familiar with the Qubes kernel? I assume it is a derivative of the Linux kernel. Is that correct? If it is which version is the current Qubes OS derived from?

I hope that helps.

Sincerely,

John Mitchell

[John Mitchell]

https://forum.level1techs.com/t/linux-host-windows-guest-gpu-passthrough-reinitialization-fix/121097

[n1ete]

>
> nVidia on the other hand strictly requires as much hiding of the VM as
> possible unless you own a Quadro and always have to add the video ROM,
> but if it's successful it just works.
> Passing the GPU between VM instances requires belief that device reset
> for such a complex device has no data leaks...
>

sorry for my inconvenience but what does that in particular mean? maybe my english skills are to bad or its too late at night. wait, its actually morning.... :D

i am one of those guys who gets an nearly mint used p52s with an unused Quadro P500 Graphics.... didnt tried any steps to accomplish passtrough because i have no need till today.but i have to admit it would be nice to have a "render" or "hashing" qube ready :D

i would fund also development, but i agree also, this shouldnt be priority for now...

qubes in general deserves to get funded & supported in any way. i think setting the right priorities over all these years constantly is why qubes can be used reliable and consistant. still a lot to do i guess :D qubes changed a lot of my workflows with ease. it makes such efficient use, in a lot of ways, of recent technology, that has grown mature over the years.
thanks!