[vfio-users] anyone else experiencing problems with Xubuntu + lock screen under nvidia card?
I documented the problem in detail at https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1815429 where you can also see VM definition. If you are able to reproduce this bug, please vote for the bugfix. TL,DR: if you are running GPU passthrough to nvidia card and running Xubuntu in the VM, then after installing nvidia drivers you will not be able to lock the screen. The workaround is to install xfwm4 version 4.13 from Mint repository. B. -- Bronek Kozicki b...@spamcop.net ___ vfio-users mailing list vfio-users@redhat.com https://www.redhat.com/mailman/listinfo/vfio-users
Re: [vfio-users] How to spoof device (sub)class ID for passthrough devices?
On Sun, 10 Feb 2019 20:01:47 +0100 Björn Ruytenberg wrote: > Hi Alex, > > Thanks for your quick response and the patch! > > I am looking into passing through a muxless GeForce GPU to a Windows guest. > > Having been through several resources, passing through muxed and desktop > cards seems quite straightforward. Either no configuration is necessary, > or exposing the (UEFI GOP) VBIOS through the ACPI _ROM method will do > the trick. From what I gather, the latter will also work with the > proprietary NVIDIA driver on Linux. However, on Windows guests, it will > simply bail out with error 43. > > I have been doing some ACPI debugging on Windows (using windbg and QEMU, > which is excellent for this :-)), and it looks like the NVIDIA driver > does several _DSM calls instead. I'm not entirely sure what these > methods do. One method contains a number of magic strings such as > `NVIDIA Certified Optimus Ready Motherboard`, which presumably lets the > driver verify it's not running in a VM. > > Rather than trying to (partially) replicate the ACPI table from the host > in the guest, I figured it might be possible to trick the NVIDIA driver > into detecting a muxed/desktop card. For this I'll need to: > > 1. Find a VBIOS with a UEFI GOP header from a non-muxless GPU, ideally > one that is the same model (muxed/desktop) or similar (Quadro). > 2. Spoof the PCI sub vendor and sub device id, or patch the VBIOS to > have these match my own card. > 3. Spoof the PCI device class, changing it from 0302 (3D controller, > i.e. muxless card) to 0300 (VGA device). > > Now that your patch enables the last, I'll try and see if this works. If > you are interested, I'd be happy to report back the results. I'm certainly curious to see what you find, I imagine others are too. When I looked at Optimus on a Thinkpad it looked like some of the _DSM calls were hooking into SMI services, so they're beyond obfuscated. Good luck! Thanks, Alex ___ vfio-users mailing list vfio-users@redhat.com https://www.redhat.com/mailman/listinfo/vfio-users
Re: [vfio-users] (good) working GPU for passthrough?
On Thu, Jan 17, 2019 at 11:03:03PM +0100, Tobias Geiger wrote: Hello! after nearly 5 years of passing through my Radeon HD7800 - it feels old and slow when used with newer games and 1GB of RAM also doesn't feel right anymore... I tried a VEGA 64 - i was able to live with the ACS patch needed here (Z170 Chipset... not needed with the old HD7800, but whatever...) - but i couldn't stand the reset/FLR/Bug which forces you at least to suspend/resume the host when you want to reboot only the guest... So my question is - AMD or NVIDIA, i dont care, cheap or superexpensive (ok, not the quadros) - what do you recommend these days for a hassle-free passthrough experienence (well at least mostly - acs patch needed would be ok, reset bug not so... it just makes it unhandy to use in day-to-day scenarios...) Wouldn't needing the ACS patch depend on your mobo as opposed to your GPU? I thought so, too! But then this: For my old HD7850 i do NOT need ACS patch, to get it working flawlessly in my Z170 Board - it works with a debian standard kernel even; The Vega 64 - in the same slot, same board - needs the ACS patch... dont ask me why... i can only guess it might have to do with the pci bridges "within" the Vega64... but thats not more than a very uneducated guess Greetings! fwiw I have had a flawless experience passing through a GTX1080 with multiple dynamic rebinding events. Thanks very much! ___ vfio-users mailing list vfio-users@redhat.com https://www.redhat.com/mailman/listinfo/vfio-users ___ vfio-users mailing list vfio-users@redhat.com https://www.redhat.com/mailman/listinfo/vfio-users ___ vfio-users mailing list vfio-users@redhat.com https://www.redhat.com/mailman/listinfo/vfio-users
Re: [vfio-users] (good) working GPU for passthrough?
On Mon, 11 Feb 2019 22:06:36 +0100 Tobias Geiger wrote: > > On Thu, Jan 17, 2019 at 11:03:03PM +0100, Tobias Geiger wrote: > >> Hello! > >> > >> after nearly 5 years of passing through my Radeon HD7800 - it feels old and > >> slow when used with newer games and 1GB of RAM also doesn't feel right > >> anymore... > >> > >> I tried a VEGA 64 - i was able to live with the ACS patch needed here (Z170 > >> Chipset... not needed with the old HD7800, but whatever...) - but i > >> couldn't > >> stand the reset/FLR/Bug which forces you at least to suspend/resume the > >> host > >> when you want to reboot only the guest... > >> > >> So my question is - AMD or NVIDIA, i dont care, cheap or superexpensive > >> (ok, > >> not the quadros) - what do you recommend these days for a hassle-free > >> passthrough experienence (well at least mostly - acs patch needed would be > >> ok, reset bug not so... it just makes it unhandy to use in day-to-day > >> scenarios...) > > Wouldn't needing the ACS patch depend on your mobo as opposed to your GPU? > > > I thought so, too! But then this: For my old HD7850 i do NOT need ACS > patch, to get it working flawlessly in my Z170 Board - it works with a > debian standard kernel even; > > The Vega 64 - in the same slot, same board - needs the ACS patch... > > dont ask me why... i can only guess it might have to do with the pci > bridges "within" the Vega64... but thats not more than a very uneducated > guess Generally the ACS patch should only depend on the motherboard unless you're trying to split the individual functions of a card to separate VMs. It shouldn't make much difference whether those functions are separate devices downstream of an on-card switch or functions within a multi-function device when assigned to a single VM. The motherboard ACS override would control things like whether separate physical slots are grouped together. We can only speculate without more data though. Thanks, Alex ___ vfio-users mailing list vfio-users@redhat.com https://www.redhat.com/mailman/listinfo/vfio-users
Re: [vfio-users] (good) working GPU for passthrough?
On 2/10/19 8:59 PM, Kash Pande wrote: > On 2019-02-10 5:25 p.m., Kyle Marek wrote: >> When I quit in the QEMU monitor, the image stays on the screen, and no >> further host dmesg output is produced. >> > You must do a full reset in the guest. Hmmm... other cards (GTX 780, GTX 1060), are reset when quitting from the monitor, so I don't have to rely on a graceful guest shutdown to avoid rebooting my host. Do I need to wait for a reset quirk to be implemented for my card to reset on quit/boot? It shouldn't be a condition to usage that the guest needs to gracefully shutdown for the card to not get stuck. signature.asc Description: OpenPGP digital signature ___ vfio-users mailing list vfio-users@redhat.com https://www.redhat.com/mailman/listinfo/vfio-users
Re: [vfio-users] (good) working GPU for passthrough?
On Mon, 11 Feb 2019 20:39:07 -0500 Kyle Marek wrote: > On 2/10/19 8:59 PM, Kash Pande wrote: > > On 2019-02-10 5:25 p.m., Kyle Marek wrote: > >> When I quit in the QEMU monitor, the image stays on the screen, and no > >> further host dmesg output is produced. > >> > > You must do a full reset in the guest. > > Hmmm... other cards (GTX 780, GTX 1060), are reset when quitting from > the monitor, so I don't have to rely on a graceful guest shutdown to > avoid rebooting my host. NVIDIA cards reset properly from a bus reset. > Do I need to wait for a reset quirk to be implemented for my card to > reset on quit/boot? It shouldn't be a condition to usage that the guest > needs to gracefully shutdown for the card to not get stuck. Don't hold your breath. ___ vfio-users mailing list vfio-users@redhat.com https://www.redhat.com/mailman/listinfo/vfio-users
