From: Alex Williamson <alex.williamson@redhat.com>
To: "Lucio Andrés Illanes Albornoz" <l.illanes@gmx.de>
Cc: Alex Deucher <alexdeucher@gmail.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] AMD video card passthrough reset issues
Date: Tue, 02 Dec 2014 08:26:20 -0700 [thread overview]
Message-ID: <1417533980.6539.11.camel@ul30vt.home> (raw)
In-Reply-To: <20141202135311.4a4fdf04@lucio-pc>
On Tue, 2014-12-02 at 13:53 +0100, Lucio Andrés Illanes Albornoz wrote:
> Hello,
>
> I'm doing secondary VGA passthrough with an AMD Radeon R7 260X using
> QEMU v2.1.2 w/ KVM and VFIO on Debian v7.7 (wheezy) (qemu v2.1
> +dfsg-5~bpo70+1 from wheezy-backports) and kernel version 3.16.5 (from
> wheezy-backports as well) and Windows 8.1 Update 1 (x64) as the guest
> OS.
>
> At present, rebooting the VM reproducibly has Windows fail to
> enable/start said video card upon bootup w/ an error code of 43, as
> seems to be the case w/ mostly everyone else running a comparable
> configuration; disabling/ejecting it before rebooting/powering down
> the VM from within the guest, as with everyone else, has proven to be
> a reliable mitigation. However, being that there are scenarios where
> this is either not feasible or impossible altogether, short of if done
> through a service or kernel-mode driver (and even then,) I had
> intended to investigate the causes behind this issue.
>
> Unfortunately, the flu got to me first (so to speak.) I did notice
> that simply removing the PCI device in question and then causing a PCI
> bus (re)scan (both) through sysfs on the host in between VM
> reboots/power cycles is effectively equivalent to disabling it within
> the guest. Thus, I find myself wondering precisely what it is that
> does take place when doing so vs. when QEMU performs a `hot reset'
> through the corresponding interface in drivers/vfio/pci/; evidently,
> the difference must be of sufficient importance since the latter
> mechanism ends up leaving my video card unavailable for subsequent VM
> operation until the next host reboot.
>
> I should very much appreciate any hints concerning whether it would be
> possible to have QEMU/VFIO perform whatever need be done itself or if
> it should be possible to have this be done by either itself.
All of the Bonaire-based AMD GPUs seems to have issues with reset
(R7790, R7 260/X). I've tried to engage AMD on this, but haven't gotten
any response on this topic yet. For devices like this that don't
support any kind of function level reset (FLR), VFIO will try to do a
PCI bus reset on guest reboot. This is as close as we can get to how
the BIOS resets the device on a host reboot. Unfortunately on these
cards there seems to be some sort of disconnect between the PCI bus
interface reset and resetting the rest of the GPU. I believe I've even
seen cases where a PCI bus reset appears to have no affect on the GPU
when running in VGA mode. My best guess is that some firmware running
in the card isn't clearing itself on reset an attempting to reload it
causes errors. Note that a guest can be reset multiple times and the
device continues to work if the guest is restricted to standard VGA
drivers (in VGA passthrough mode of course).
In your experiment with removing and rescanning the device, are you
simply doing 'echo 1 > remove; echo 1 > /sys/bus/pci/rescan'? Thanks,
Alex
next prev parent reply other threads:[~2014-12-02 15:26 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-02 12:53 [Qemu-devel] AMD video card passthrough reset issues Lucio Andrés Illanes Albornoz
2014-12-02 15:26 ` Alex Williamson [this message]
2014-12-02 16:14 ` Lucio Andrés Illanes Albornoz
2014-12-08 14:11 ` Lucio Andrés Illanes Albornoz
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=1417533980.6539.11.camel@ul30vt.home \
--to=alex.williamson@redhat.com \
--cc=alexdeucher@gmail.com \
--cc=l.illanes@gmx.de \
--cc=qemu-devel@nongnu.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).