From: nucleare2 <nucleare2@protonmail.com>
To: "kvm@vger.kernel.org" <kvm@vger.kernel.org>
Subject: Re: GPU passthrough hot-swapping driver development?
Date: Sun, 02 Jun 2019 20:49:35 +0000 [thread overview]
Message-ID: <NSZOGDLSVPu40Ch8eOrf0JQaHx53jz3bJr3ObXdpT6riMCAcivu6wVdRC61HE1fkMnOMTUIysb00W4BqDhpIg3EALXCHPl_ZCECBRtGNstI=@protonmail.com> (raw)
In-Reply-To: <7m5yGq2nqhDfQvcZCjBDqj8OEu2o1QDrqiy-MdHrni7Qw8rwHrdkBMtEisMnEG1dgB6lSJI-MleT0EAlkZE28gRfQqjXJsDRlCgsNJw7oPQ=@protonmail.com>
Given that there's been no response yet, I wanted to hopefully clarify what I'm talking about by providing a couple diagrams and maybe some clarifying terminology. I'm not sure if these diagrams will look right for everyone, so I'll also include a link to an image for each one above it.
First, please correct me if I'm wrong, but I believe the following diagram represents a very basic visualization of KVM + QEMU:
Image: https://i.ibb.co/smh9Rv4/KVM-and-QEMU.png
┌───────────────┐ ┌──────────────┐ ┌──────────────┐
│ Native │ │ Guest │ │ Guest │
│ Software │ │ VM │ │ VM │
│ │ │ │ │ │
│ │ │ │ │ │
│ │ │ │ │ │
│ │ │ │ │ │
└───────┬───────┘ │ │ │ │
│ │ │ │ │
│ │ │ │ │
│ │ │ │ │
│ │ ║ │ │ │
│ ├──────╬───────┴───┴──────────────┤
│ │ ║ QEMU │
│ │ ║ │
│ └──────╬────────────────┬─────────┘
│ ║ GPU │
│ ║Passthru │
│ ╚════════╗ │
┌───────▼───────────────────────────╬───────┼─────────┐
│ ┌──╬───────▼──────┐ │
│Linux (kernel) │ ║ KVM │ │
│ └──╬──────────────┘ │
└───────────────────────────┬───────╬─────────────────┘
┌───────────────────────────▼───────╬─────────────────┐
│ ║ │
│ ┌─────────┐┌──────▼──┐ ┌─────────┐│
│HARDWARE │ GPU1 ││ │ │ ││
│ │ (host ││ GPU2 │...│ GPUn ││
│ │reserved)││ │ │ ││
│ └─────────┘└─────────┘ └─────────┘│
└─────────────────────────────────────────────────────┘
What I'm considering or asking about is the development of something I'll call a "soft video switch" within Linux that perhaps lives beside KVM or somehow works with KVM to facilitate quick switching between direct passthrough of graphics for the HOST or GUEST(s):
Image: https://i.ibb.co/gSLybZy/KVM-and-QEMU-with-soft-video-switch.png
││
┌───────────────┐ ┌──────────────┐ ┌──────────────┐ ╔═════════════════════════════════════════╗
│ Native │ │ Guest │ │ Guest │ ││ ║ EXPANDED VIEW of "soft video switch" ║
│ Software │ │ VM │ │ VM │ ║ ║
│ │ │ │ │ │ ││ ║───────direct guest video──┐ ║
│ │ │ │ │ │ ║ driver access │ ║
│ │ │ │ │ │ ││ ║────────────────┐ │ ║
│ │ │ │ │ │ ║ direct host video │ ║
└───────┬───────┘ │ │ │ │ ││ ║ driver access │ ║
│ │ │ │ │ ║ ┌──────▼──────────▼──────┐ ║
│ │ │ │ │ ││ ║ │ soft video switch │ ║
│ │ ║ │ │ │ ║ │ │ ║
│ │ ║ │ │ │ ││ ║ │ Λ │ ║
│ ├──────╬───────┴───┴──────────────┤ ║ │ ╱ ╲ │ ║
│ │ ║ QEMU │ ││ ║ │ ╱ ╲ │ ║
│ │ ║ │ ║ │ ╱ ╲ │ ║
│ └──────╬────────────────┬─────────┘ ││ ║ │ ┌──▕ ▏───┐ │ ║
│ ║ GPU │ ║ │ │ ╲ ╱ │ │ ║
│ ║ Passthru │ ││ ║ │ │ ╲ ╱ │ │ ║
│ ╚══════════╗ │ ║ │ │ ╲ ╱ │ │ ║
┌───────▼─────────────────────────────╬─────┼─────────┐ ││ ║ │ Active V Inactive │ ║
│LINUX (kernel) ┌─────────────┐┌────╬─────▼──────┐ │ ║ │ Input Input │ ║
│ │system video ││ ║ KVM │ │ ││ ║ │ │ │ │ ║
│ │ driver ││ ║ │ │ ║ └────┼──────────────┼────┘ ║
│ └──────┬──────┘└────╬────────────┘ │ ││ ║ │ │ ║
│ │ ║ │ ║ ┌────▼─────┐ ┌─────▼────┐ ║
│ └──┐ ║ │ ││ ▷║ │ │ │ │ ║
│ │ ║ see ╱ ║ │ GPU │ │/dev/null │ ║
│ ┌─▼─────────▼─┐ ╱─────expanded ╱ ║ │ │ │ │ ║
│ │ soft video │ ╱ view ║ └──────────┘ └──────────┘ ║
│ │ switch │▷ (right)││ ║ ┌───────────────────────────────────┐ ║
│ └──────┬──────┘ │ ╚══╣ NOTE: User presses some key ╠══╝
└─────────────┬──────────────────┼────────────────────┘ ││ │ combination (example: │
│ │ │ control-alt-shift-ESC) to toggle │
┌─────────────▼──────────────────┼────────────────────┐ ││ │ between which "OS" get's ACTIVE │
│HARDWARE │ │ │ direct GPU access while the │
│ ┌────▼────┐ │ ││ │ INACTIVE "OS" is discarded. │
│ │ │ │ └───────────────────────────────────┘
│ │ GPU │ │ ││
│ │ │ │
│ └─────────┘ │ ││
└─────────────────────────────────────────────────────┘
││
If I'm missing any diagrammatic details, I would very much appreciate some correction. Further, I'd like to discuss what could stop the development of such a "soft video switch" as explained above.
Thanks for any input here!
-nuc
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Saturday, June 1, 2019 6:07 PM, nucleare2 <nucleare2@protonmail.com> wrote:
> 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
next prev parent reply other threads:[~2019-06-02 20:49 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-01 22:07 GPU passthrough hot-swapping driver development? nucleare2
2019-06-02 20:49 ` nucleare2 [this message]
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='NSZOGDLSVPu40Ch8eOrf0JQaHx53jz3bJr3ObXdpT6riMCAcivu6wVdRC61HE1fkMnOMTUIysb00W4BqDhpIg3EALXCHPl_ZCECBRtGNstI=@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.