All of lore.kernel.org
 help / color / mirror / Atom feed
From: nucleare2 <nucleare2@protonmail.com>
To: "kvm@vger.kernel.org" <kvm@vger.kernel.org>
Subject: GPU passthrough hot-swapping driver development?
Date: Sat, 01 Jun 2019 22:07:59 +0000	[thread overview]
Message-ID: <7m5yGq2nqhDfQvcZCjBDqj8OEu2o1QDrqiy-MdHrni7Qw8rwHrdkBMtEisMnEG1dgB6lSJI-MleT0EAlkZE28gRfQqjXJsDRlCgsNJw7oPQ=@protonmail.com> (raw)

Hello, I'd like to discuss the possibility of developing a method for hot-swapping video cards between a KVM host and the guest machine when using passthrough.

It seems that currently passthrough is pretty restrictive as far as assignment to the host vs guest goes.  This means for applications like accelerating macOS fully a video card needs to be dedicated to passthrough for macOS so that native drivers grab a hold of it at macOS guest startup.

I've been thinking about the possibility of creating some kind of a dummy passthrough driver that may, at some minimal level, virtualize the GPU access so as to allow the KVM host and guest (macOS, Windows, Linux, whatever would need the full GPU access) to "hot-swap" access to the GPU.

As I said above, right now it appears that it's necessary to have multiple GPUs for the host vs guests that need/want passthrough, but if an appropriate driver is developed that somehow captures some core functionality, couldn't a kernel level key combination capture be implemented that would flip passthrough between host and guest(s)?

Basically if a macOS or Windows (or Linux) guest BELIEVES it still has control of the GPU, then the guest kernel should not panic and should still remain operational while the host get's access.  I'm not talking about any kind of capturing here, just simply making the host or guest think it's still getting GPU access and happily spinning away while the user is flipping between host/guest instances.

Has anyone considered this or put any work into this so far?

I've seen someone else mention this before somewhere, but it seemed to not get any attention. This is a pretty critical function that would benefit KVM users enormously.

-nuc

             reply	other threads:[~2019-06-01 22:08 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-01 22:07 nucleare2 [this message]
2019-06-02 20:49 ` GPU passthrough hot-swapping driver development? nucleare2
2019-06-02 20:57   ` nucleare2

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='7m5yGq2nqhDfQvcZCjBDqj8OEu2o1QDrqiy-MdHrni7Qw8rwHrdkBMtEisMnEG1dgB6lSJI-MleT0EAlkZE28gRfQqjXJsDRlCgsNJw7oPQ=@protonmail.com' \
    --to=nucleare2@protonmail.com \
    --cc=kvm@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.