[vfio-users] Question about integrated GPU passthrough and initialization

[Micah Morton]

Ok thanks, I figured out my issue. Turns out SeaBIOS in the VM tries
to map from 0x100000-0x8000000 as "System RAM" (which holds the kernel
code/data/bss sections). On my device the sbios usually only maps
0x100000-0x7a988fff for this purpose. So when the i915 driver tries to
reserve 0x7c000000-0x7fffffff for the "Graphics Stolen Memory" this
normally succeeds on my device but fails in the VM since the kernel
sees something already mapping this area of memory. This can be fixed
by patching SeaBIOS to only reserve up through 0x7bffffff for the
"System RAM" for the kernel. Somehow the 4.14 kernel is smart enough
to remap 0x7c000000-0x7fffffff for the Graphics Stolen Memory even if
it has been claimed by SeaBIOS for System RAM (so this problem doesn't
show up when running 4.14 in the VM), but 4.4 is not. I'm trying to
get the 4.4 kernel working in the VM since I think those drivers have
been more thoroughly tested for my hardware.

On Mon, Jun 3, 2019 at 3:51 PM Alex Williamson
<alex.williamson at redhat.com> wrote:
>
> On Mon, 3 Jun 2019 14:38:49 -0700
> Micah Morton <mortonm at chromium.org> wrote:
>
> > Hi Alex,
> >
> > Could you remind me whether there is a minimum recommended kernel
> > version to be running in the VM guest when doing GPU passthrough?
> >
> > I'm fine running 4.14 in the host, but was looking to see if I could
> > run 4.4 in the guest and couldn't remember if it is advised to use a
> > newer kernel in the guest or if there is any reason to have the guest
> > kernel match the host kernel version?
>
> I don't recall any specific guest version dependency.  I've got an old
> 4.9 guest around and that's about the only direct IGD assignment VM I
> test on a semi-regular basis.  I do keep that host relatively updated,
> so it's currently a 5.0/4.9 combination.  No reason to keep them in sync
> that I know of.  Thanks,
>
> Alex