GPU passthrough support for Stoney [Radeon R2/R3/R4/R5 Graphics]?

[Micah Morton]

On Thu, May 16, 2019 at 1:39 PM Alex Deucher <alexdeucher at gmail.com> wrote:
>
> On Thu, May 16, 2019 at 4:07 PM Micah Morton <mortonm at chromium.org> wrote:
> >
> > On Wed, May 15, 2019 at 7:19 PM Alex Deucher <alexdeucher at gmail.com> wrote:
> > >
> > > On Wed, May 15, 2019 at 2:26 PM Micah Morton <mortonm at chromium.org> wrote:
> > > >
> > > > Hi folks,
> > > >
> > > > I'm interested in running a VM on a system with an integrated Stoney
> > > > [Radeon R2/R3/R4/R5 Graphics] card and passing through the graphics
> > > > card to the VM using the IOMMU. I'm wondering whether this is feasible
> > > > and supposed to be doable with the right setup (as opposed to passing
> > > > a discrete GPU to the VM, which I think is definitely doable?).
> > > >
> > > > So far, I can do all the qemu/kvm/vfio/iommu stuff to run the VM and
> > > > pass the integrated GPU to it, but the drm driver in the VM fails
> > > > during amdgpu_device_init(). Specifically, the logs show the SMU being
> > > > unresponsive, which leads to a 'SMU firmware load failed' error
> > > > message and kernel panic. I can share VM logs and the invocation of
> > > > qemu and such if helpful, but first wanted to know at a high level if
> > > > this should be feasible?
> > > >
> > > > P.S.: I'm not initializing the GPU in the host bios or host kernel at
> > > > all, so I should be passing a fresh GPU to the VM. Also, I'm pretty
> > > > sure I'm running the correct VGA bios for this GPU in the guest VM
> > > > bios before guest boot.
> > > >
> > > > Any comments/suggestions would be appreciated!
> > >
> > > It should work in at least once as long as your vm is properly set up.
> >
> > Is there any reason running coreboot vs UEFI at host boot would make a
> > difference? I was running a modified version of coreboot that avoids
> > doing any GPU initialization in firmware -- so the first POST happens
> > inside the guest.
>
> The GPU on APUs shares a bunch of resources with the CPU.  There are a
> bunch of blocks which are shared and need to be initialized on both
> for everything to work properly.

Interesting. So skipping running the vbios in the host and waiting
until running it for the first time in the guest SeaBIOS is a bad
idea? Would it be better to let APU+CPU initialize normally in the
host and then skip trying to run the vbios in guest SeaBIOS and just
do some kind of reset before the drm driver starts accessing it from
the guest?

>
> >
> > > Note that the driver needs access to the vbios image in the guest to
> > > get device specific configuration details (clocks, display connector
> > > configuration, etc.).
> >
> > Is there anything I need to do to ensure this besides passing '-device
> > vfio-pci,...,romfile=/path/to/vgarom' to qemu?
>
> You need the actual vbios rom image from your system.  The image is
> board specific.

I should have the correct vbios rom image for my board. I'm extracting
it from the firmware image (that works for regular graphics init
without this VM stuff) for the board at build time (rather than
grabbing it from /sys/devices/pci... at runtime), so it shouldn't be
modified or corrupted in any way.

>
> Alex