[SOLVED] Planning for a Slackware host & Win7 guest, need advice.

Hey everyone! I'm looking to make a slackware-based Qemu/KVM system with GPU-passthrough so I can for-good segregate windows from the rest of my world.

the last time I tried using Qemu/KVM, I had also used a little thing called "vms", and although I downloaded spice, tigervnc, and I think xrdp, I can't remember what I used. Long story short, this was the straw that broke the camel's back for me, and I gave up for a year after the windows guest wouldn't stop bluescreening after I installed the drivers.

That was on a 2018 build of slackware-current, now I'm wondering if I should stick to 14.2 for stability's sake, or use current to get the most up to date things. Leaning towards 14.2.

So beyond the OS questions, I have some Qemu questions to extend my original post in the slackware forums

• What other tools, software would I need to make hardware-passed Qemu guests more usable?
• How should I configure an intrusion detection system (such as snort) to keep the guest from poking around where it doesn't belong on the host?
• How does software like Xrdp, Spice and TigerVNC fit into the picture with virtualization?
• (curiosity on this one, but not an essential question) What would cause a win7 guest to bluescreen after installing the GPU's drivers on the guest?

Original Slackware Forums Thread - contains my hardware specs among things
https://www.linuxquestions.org/quest...ce-4175665040/

Thank you!

I can share my opinion on these points

Originally Posted by lawnm0wer How does software like Xrdp, Spice and TigerVNC fit into the picture with virtualization? (curiosity on this one, but not an essential question) What would cause a win7 guest to bluescreen after installing the GPU's drivers on the guest?

VNC, RDP and Spice are protocols that allow sharing the guest's display buffer with a network-connected client. This allows you to see the guest's system console on the client, including graphics. I am not sure how they interact with a pass-through GPU.

The GPU drivers probably expect hardware that is different from what they actually "see". For example they may attempt to access a memory-mapped GPU register at an address that doesn't exist. I would guess that the way the GPU is mapped into the guest's physical address space is incompatible with the drivers' expectations.

Originally Posted by berndbausch The GPU drivers probably expect hardware that is different from what they actually "see". For example they may attempt to access a memory-mapped GPU register at an address that doesn't exist. I would guess that the way the GPU is mapped into the guest's physical address space is incompatible with the drivers' expectations.

interesting. I think I understand what you're talking about, but I'm not sure how I would apply a fix, or if that would even apply to the slackware version I would end up using.

What should I use to find and provide information about problems like this so I or others can resolve future problems like this?

Sounds to me like you're confusing GPU passthrough with a virtualized GPU.

A virtualized GPU, aka virgl, is creating a paravirtualized GPU in the virtual machine that gets accelerated by any hardware acceleration on the host. This is the GPU equivalent of doing something like assigning 2 virtual CPUs with 2 virtual threads to a VM. This would let you use stuff like VNC. It is in the early stages of development and currently has, I think, a lot of processing overhead.

A GPU passthrough is assigning a physical GPU to a guest machine using PCI passthrough. When this is done, the host doesn't see or use the guest assigned GPU at all. This is what currently produces the near-native performance for a Windows machine running as a guest on Linux. Usually, the chipset provided video, or that of another card is used by the Linux desktop. The dedicated GPU and an additional keyboard and mouse are assigned for the sole use of the Windows guest. I think, but I am not 100% sure, that you would need to run that video output back into some sort of capture mechanism on the Linux host to then make it available through something like VNC. That is, if that can even be done with captured output, while connecting a keyboard and mouse to that datastream. Basically, every time I have seen any info about GPU passthrough, the setup involved two mice, keyboards and monitors connected to the machine.

Originally Posted by Luridis Sounds to me like you're confusing GPU passthrough with a virtualized GPU. A virtualized GPU, aka virgl, is creating a paravirtualized GPU in the virtual machine that gets accelerated by any hardware acceleration on the host. This is the GPU equivalent of doing something like assigning 2 virtual CPUs with 2 virtual threads to a VM. This would let you use stuff like VNC. It is in the early stages of development and currently has, I think, a lot of processing overhead. A GPU passthrough is assigning a physical GPU to a guest machine using PCI passthrough. When this is done, the host doesn't see or use the guest assigned GPU at all. This is what currently produces the near-native performance for a Windows machine running as a guest on Linux. Usually, the chipset provided video, or that of another card is used by the Linux desktop. The dedicated GPU and an additional keyboard and mouse are assigned for the sole use of the Windows guest. I think, but I am not 100% sure, that you would need to run that video output back into some sort of capture mechanism on the Linux host to then make it available through something like VNC. That is, if that can even be done with captured output, while connecting a keyboard and mouse to that datastream. Basically, every time I have seen any info about GPU passthrough, the setup involved two mice, keyboards and monitors connected to the machine.

Well this explains all the confusion and screw-ups I've been having. I remember buying a KvM switch for the sole purpose of setting up a passed-through VM, so I think I might be able to get that to work, it'll just be a matter of me going back through the KVM steps to figure out how to make things work. so consider this one solved.

Thank you!

Originally Posted by lawnm0wer Well this explains all the confusion and screw-ups I've been having. I remember buying a KvM switch for the sole purpose of setting up a passed-through VM, so I think I might be able to get that to work, it'll just be a matter of me going back through the KVM steps to figure out how to make things work. so consider this one solved. Thank you!

While I think the monitor switching would work, I'm not sure the keyboard & mouse switching would. The KvM switch is likely act like a usb hub and send your keyboard an mouse USB ID's to the host system. Since those ID's will be assigned to your host, if you redirect them to the guest you'll lose control of the host when you switch the monitor back. I'm reasonably sure you'd need inputs with different ID's so that you can filter them off to the guest in the VM configuration. This, and the ability to tweak on the host while you're using the guest is probably why I've only seen this setup with two inputs and outputs.