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.william...@redhat.com> wrote: > > On Mon, 3 Jun 2019 14:38:49 -0700 > Micah Morton <mort...@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 _______________________________________________ vfio-users mailing list vfio-users@redhat.com https://www.redhat.com/mailman/listinfo/vfio-users
