On Thu, 26 Apr 2018 14:46:08 +0200
Tony Cheneau <tony.cheneau@xxxxxxxxxxxx> wrote:
> Hello folks,
>
> A colleague and I are trying to get legacy passthrough to work with a HP
> Probook
> 430 G4 in BIOS mode. This is part of a "bigger" pet project where we are
> trying
> to use legacy passthrough on all our laptop that have a working IOMMU and
> compatible hardware. Ultimately, we trying to run a Windows 10 guest within
> that
> VM.
>
> We've experienced a success using a same generation IGD (on Lenovo Thinkpad
> X260) where we got legacy passthrough to work and that encouraged us to
> push
> things further. We're now asking for help because we can't seem to find how
> to
> get it to work on an HP Probook G4. Qemu is stuck when loading the VBIOS.
>
> Here is the command line for starting the VM:
> $ qemu-system-x86_64 -D /var/log/qemu.log \
> -serial file:/root/serial.logs -monitor stdio \
> -bios /root/seabios-debug.bin -smbios type=0 \
> -m 6G -enable-kvm -machine pc,accel=kvm \
> -rtc driftfix=slew,base=localtime \
> -cpu
> host,hv_relaxed,hv_reset,hv_vpindex,hv_runtime,hv_spinlocks=0x1fff,hv_vapic,hv_time,kvm=off
> \
> -smp sockets=1,cores=2,threads=2 \
> -drive format=qcow2,file=/root/windows.qcow2,index=0,if=virtio \
> -vga none -display none -device
> vfio-pci,host=00:02.0,id=hostdev0,bus=pci.0,addr=0x02,romfile=/root/image.rom,x-igd-gms=1
> \
> -device
> virtio-input-host-pci,evdev=/dev/input/by-path/platform-i8042-serio-0-event-kbd
> \
> -device
> virtio-input-host-pci,evdev=/dev/input/by-path/platform-i8042-serio-3-event-mouse
> \
> -net nic,model=virtio,addr=0x14 -net user
>
> The image.rom VBIOS image has been extracted from a firmware update for HP
> laptop (using UEFI tool) and patched with rom-fixer. The firmware update is
> confirmed to be compatible with this laptop (it applied without bricking
> the
> laptop). We also tried using VBIOS from other hardware, but qemu then
> rejects it
> ("Turning on vga text mode console" error message).
The VBIOS seems pretty suspect here, are you scraping it out of the
firmware update image because the laptop is running in UEFI mode and
doesn't expose a PCI ROM? A strategy that I've used for such a case is
to enable legacy boot in the BIOS, boot a live CD and use that to dump
the ROM. Stash it somewhere, revert the BIOS changes, use rom-fixer to
cleanup the new image and see if it behaves more reasonably. (BTW,
kvm=off should only ever be necessary for GeForce assignment)
[snip]
> As a side note, we never managed to get the UPT mode to output on the
> displays
> (even on the Thinkpad X260, where legacy PT works). Perhaps because we
> tried on
> a Q35/UEFI platform back then. On the guest, we got rid of the "error 43"
> in
> Windows after updating to the latest intel driver. Also, it always
> indicates
> the presence of a second monitor in the configuration dialogs (even without
> the
> x-igd-opregion=on option which make me doubt the actual screen is even
> detected).
Display output in UPT mode requires opregion support, but OVMF doesn't
include any support for the fw_cfg used to handle that, so it would be
expected not to get output in this configuration.
> On the Lenovo X260, we were luckier with the Q35/Seabios combo: we managed
> once to get the external display to work and even then the internal display
> had
> brightness issues and was unreadable.
It might depend on the system how brightness is wired, it's not
entirely clear that a VM owning the GPU also necessarily owns the
hardware necessary for brightness.
> We identified some differences between our test hardware:
> - HP Probook's processor is a i3-7100U (Kabylake), graphic chip is a Intel
> HD Graphics 620 (8086:5916)
> - Lenovo X260's processor is a i3-6100U (Skylake), graphic chip is a Intel
> HD Graphics 520 GT2 (8086:1916)
>
> On the Linux host, we are using:
> - a mix of linux Kernel 4.15.15 (for some early tests) and 4.16 (for all
> the debug output in the email)
> - Qemu 2.12 or git master (HEAD of master on 4/25/2018)
>
> We believe that Qemu could currently be lacking support for Gen9 KBL_GT2
> graphics chips and that some memory regions need to be "reserved/mapped" or
> some
> "stolen memory" should be declared (we are clearly not expert here, we just
> looked at how the previous commits on pci_quirks.c handled newer generation
> IGD
> hardware in Qemu).
Entirely possible. IIRC we initially had a lot or reports of corrupted
displays with the i3-6100U but I think we fixed that by recognizing a
different page table format when programming the GTT. Intel seems to
change the GPU hardware on a whim, but I haven't specifically heard of
issues with Kabylake.
> We haven't ruled out yet that an interrupt could be
> triggered
> and we would be enterring an interrupt loop. We are a little at odds on how
> to
> direct our debug next:
> - do you know ways to check for memory write error in Qemu (in case the
> device
> is trying to communicate with a memory region that have not been mapped)?
Uncomment memory.c://#define DEBUG_UNASSIGNED
You'll also want to enable vfio* tracing and configure the vfio-device
with x-no-mmap=on to see all the interactions with the device.
> - how do we check for interrupt loop?
I don't think the VBIOS is doing anything with device interrupts but
there are a series of vfio-pci x-no-kvm-foo options that disable
interrupt bypass through KVM so you can see them in the traces. Good
luck!
Alex
