<div dir="ltr">Hi,<div><br></div><div>Following <a href="https://medium.com/@calerogers/gpu-virtualization-with-kvm-qemu-63ca98a6a172">this guide</a> before, I had already tried the vbios-romdump route, but now with a lot of other stuff checked of, I gave it another try:<br><div><br></div><div>1. booted a live linux from a usb-stick on the host with cms enabled, making sure not to use uefi while booting<br></div><div>2. dumped the vga-bios</div><div>3. ran the dump through rom-parser</div><div>4. created rom-dump<br></div><div>At this point I got a bit confused: as i understand correctly, rom-parser is only for viewing, rom-fixer for editing. As I noticed that the device id didn't correspond with the one reported by lspci -nnk, I made a few version of the dump with changed device id's, and having rom-fixer correct the checksum. If it doesn't help, it can't hurt either.</div><div><br></div><div>this is what lspci -nnk reported:</div><div>VGA compatible controller [0300]: Intel Corporation Device <i>[8086:5a85]</i> (rev 0b)</div><div><div>Subsystem: ASRock Incorporation Device <i><u>[1849:5a85]</u></i></div></div><div><br></div><div>So I made and tested following dumps in the vm, following the vendor and device id's from the lspci -nnk:</div><div>a) original dump (not changed): vendor id <i>8086</i> (Intel), device id <i>0406</i> (unknown)</div><div>b) dump with changed device id: vendor id <i>8086</i> (Intel) and device id <i>5a85</i> (Intel HD500)</div><div>c) dump with changed vendor id and device id: vendor id <i>1849</i> (Asrock), device id <i>5a85</i> (Intel HD500)</div><div><br></div><div>This proved to be useless, as there was no difference in output when either one of the versions was used.</div><div><br></div><div>5. added the path to the vm.xml<br></div><div><rom bar='on' file='/var/lib/libvirt/vbios_dump/vbios_intel_HD500.rom'/></div><div><br></div><div>The rom bar='on' was added by virt-manager (as also documented <a href="https://doc.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/Virtualization_Deployment_and_Administration_Guide/sub-sub-section-libvirt-dom-xml-devices-interface-ROM-BIOS-configuration.html">here</a>), and provided some interesting results:</div><div><br></div><div>With rom bar='off', the results were identical to the situation before (where rom bar was on, but no vga-bios-rom-file specified): black screen (that powers off), 1 of the  4 assigned virtual cpu's maxing out, as well as the virtual memory. Also the messages in dmesg were identical to before.</div><div><br></div><div>With rom bar='on', this time the vm refused to start, and I got below error messages in the virsh console:</div><div><br></div><div>error: Failed to start domain ubuntu16.04_desktop</div><div>error: internal error: process exited while connecting to monitor: warning: host doesn't support requested feature: CPUID.01H:EDX.ds [bit 21]</div><div>warning: host doesn't support requested feature: CPUID.01H:EDX.acpi [bit 22]</div><div>warning: host doesn't support requested feature: CPUID.01H:EDX.ht [bit 28]</div><div>warning: host doesn't support requested feature: CPUID.01H:EDX.tm [bit 29]</div><div>warning: host doesn't support requested feature: CPUID.01H:EDX.pbe [bit 31]</div><div>warning: host doesn't support requested feature: CPUID.01H:ECX.dtes64 [bit 2]</div><div>warning: host doesn't support requested feature: CPUID.01H:ECX.monitor [bit 3]</div><div>warning: host doesn't support requested feature: CPUID.01H:ECX.ds-cpl [bit 4]</div><div>warning: host doesn't support requested feature: CPUID.01H:ECX.est [bit 7]</div><div>warning: host doesn't support requested feature: CPUID.01H:ECX.tm2 [bit 8]</div><div>warning: host doesn't support requested feature: CPUID.01H:ECX.xtpr [bit 14]</div><div>warning: host doesn't support requested feature: CPUID.01H:ECX.pdcm [bit 15]</div><div>warning: host doesn't support requested feature: CPUID.01H:EC</div><div><br></div><div>Notice the final line not being complete. Often, this last line would go on to:</div><div><br></div><div>warning: host doesn't support requested feature: CPUID.01H:ECX.osxs<br></div><div><br></div><div>Even stranger is the fact that even if I enter a path to a non-existent file, the result and error message will be the same. Doublechecked rights and path.</div><div><br></div><div>Running the .xml with only <rom bar='on'> (and no rom-file specified) is what I was running before with the usual result (black screen, no errors). Same when I remove all pci-passthrough-, video- and graphics devices.</div><div><br></div><div>If there is any other info I can provide or something I can try, I would gladly do so. Thanks for any suggestions.</div><div><br></div><div>Kind regards,<br></div><div><br></div><div>Geert</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 27 July 2017 at 17:41, Alex Williamson <span dir="ltr"><<a href="mailto:alex.williamson@redhat.com" target="_blank">alex.williamson@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, 27 Jul 2017 11:32:24 +0200<br>
<span class="">Geert Coulommier <<a href="mailto:g.coulommier@gmail.com">g.coulommier@gmail.com</a>> wrote:<br>
<br>
> Hi,<br>
><br>
</span><span class="">> so I've tried the 2 options you suggested:<br>
><br>
> 1) "look in /proc/iomem and identify the driver that's still claiming<br>
> portions of IGD and disable it"<br>
><br>
> from /proc/iomem:<br>
><br>
> ...<br>
> 80000000-cfffffff : PCI Bus 0000:00<br>
>   80000000-8fffffff : 0000:00:02.0<br>
>     80000000-808cffff : efifb<br>
> ...<br>
><br>
> which is strange as to prevent this, the part "video=efifb:off" was added<br>
> to grub:<br>
><br>
> GRUB_CMDLINE_LINUX_DEFAULT="<wbr>quiet splash intel_iommu=on iommu=pt<br>
> rd.driver.pre=vfio-pci video=vesafb:off,efifb:off"<br>
><br>
> Because I'm running the host on uefi, and to keeps things clean, I removed<br>
</span>  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^<wbr>^^^^^^<br>
<br>
This is probably the next piece of the puzzle...<br>
<div><div class="h5"><br>
> the "vesafb:off"-part:<br>
> GRUB_CMDLINE_LINUX_DEFAULT="<wbr>quiet splash intel_iommu=on iommu=pt<br>
> rd.driver.pre=vfio-pci video=efifb:off"<br>
><br>
> Unexpectedly, this seemed have an effect. Now from /proc/iomem (when not<br>
> running the VM,full printout of /proc/iomem below in [1]):<br>
><br>
> ...<br>
> 80000000-cfffffff : PCI Bus 0000:00<br>
>   80000000-8fffffff : 0000:00:02.0<br>
>   90000000-90ffffff : 0000:00:02.0<br>
>   91000000-910fffff : 0000:00:0e.0<br>
>   91100000-911fffff : PCI Bus 0000:03<br>
>     91100000-911001ff : 0000:03:00.0<br>
>       91100000-911001ff : ahci<br>
> ...<br>
><br>
> when running the VM, it goes to:<br>
><br>
> ...<br>
> 80000000-cfffffff : PCI Bus 0000:00<br>
>   80000000-8fffffff : 0000:00:02.0<br>
>     80000000-8fffffff : vfio-pci<br>
>   90000000-90ffffff : 0000:00:02.0<br>
>     90000000-90ffffff : vfio-pci<br>
>   91000000-910fffff : 0000:00:0e.0<br>
>     91000000-910fffff : vfio-pci<br>
>   91100000-911fffff : PCI Bus 0000:03<br>
>     91100000-911001ff : 0000:03:00.0<br>
>       91100000-911001ff : ahci<br>
>   91200000-912fffff : PCI Bus 0000:01<br>
>     91200000-91203fff : 0000:01:00.0<br>
>       91200000-91203fff : r8169<br>
>     91204000-91204fff : 0000:01:00.0<br>
>       91204000-91204fff : r8169<br>
>   91300000-9130ffff : 0000:00:15.0<br>
>     91300000-9130ffff : xhci-hcd<br>
>   91310000-91313fff : 0000:00:0e.0<br>
>     91310000-91313fff : vfio-pci<br>
>   91314000-91315fff : 0000:00:12.0<br>
>     91314000-91315fff : ahci<br>
>   91316000-913160ff : 0000:00:1f.1<br>
>   91317000-913177ff : 0000:00:12.0<br>
>     91317000-913177ff : ahci<br>
>   91318000-913180ff : 0000:00:12.0<br>
>     91318000-913180ff : ahci<br>
>   9131b000-9131bfff : 0000:00:0f.0<br>
>     9131b000-9131bfff : mei_me<br>
> ...<br>
><br>
><br>
> and the dmesg log:<br>
><br>
> dmesg | grep -aiE '((DMAR)|(kvm)|(drm)|(Command line)|(iommu)|(vfio))'<br>
> [    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.12.<wbr>3-041203-generic<br>
> root=/dev/mapper/granada--vg-<wbr>root ro quiet splash intel_iommu=on iommu=pt<br>
> rd.driver.pre=vfio-pci video=efifb:off vt.handoff=7<br>
> [    0.000000] ACPI: DMAR 0x000000006D9D0470 0000A8 (v01 INTEL  EDK2<br>
> 00000003 BRXT 0100000D)<br>
> [    0.000000] Kernel command line:<br>
> BOOT_IMAGE=/boot/vmlinuz-4.12.<wbr>3-041203-generic<br>
> root=/dev/mapper/granada--vg-<wbr>root ro quiet splash intel_iommu=on iommu=pt<br>
> rd.driver.pre=vfio-pci video=efifb:off vt.handoff=7<br>
> [    0.000000] DMAR: IOMMU enabled<br>
> [    0.044107] DMAR: Host address width 39<br>
> [    0.044109] DMAR: DRHD base: 0x000000fed64000 flags: 0x0<br>
> [    0.044126] DMAR: dmar0: reg_base_addr fed64000 ver 1:0 cap<br>
> 1c0000c40660462 ecap 7e3ff0505e<br>
> [    0.044128] DMAR: DRHD base: 0x000000fed65000 flags: 0x1<br>
> [    0.044139] DMAR: dmar1: reg_base_addr fed65000 ver 1:0 cap<br>
> d2008c40660462 ecap f050da<br>
> [    0.044142] DMAR: RMRR base: 0x0000006d5af000 end: 0x0000006d5cefff<br>
> [    0.044145] DMAR: RMRR base: 0x0000006f800000 end: 0x0000007fffffff<br>
> [    0.044148] DMAR-IR: IOAPIC id 1 under DRHD base  0xfed65000 IOMMU 1<br>
> [    0.044150] DMAR-IR: HPET id 0 under DRHD base 0xfed65000<br>
> [    0.044152] DMAR-IR: Queued invalidation will be enabled to support<br>
> x2apic and Intr-remapping.<br>
> [    0.046253] DMAR-IR: Enabled IRQ remapping in x2apic mode<br>
> [    1.794596] DMAR: No ATSR found<br>
> [    1.795685] DMAR: dmar0: Using Queued invalidation<br>
> [    1.795694] DMAR: dmar1: Using Queued invalidation<br>
> [    1.795872] DMAR: Hardware identity mapping for device 0000:00:00.0<br>
> [    1.795882] DMAR: Hardware identity mapping for device 0000:00:02.0<br>
> [    1.795886] DMAR: Hardware identity mapping for device 0000:00:0e.0<br>
> [    1.795888] DMAR: Hardware identity mapping for device 0000:00:0f.0<br>
> [    1.795890] DMAR: Hardware identity mapping for device 0000:00:12.0<br>
> [    1.795892] DMAR: Hardware identity mapping for device 0000:00:13.0<br>
> [    1.795895] DMAR: Hardware identity mapping for device 0000:00:13.1<br>
> [    1.795897] DMAR: Hardware identity mapping for device 0000:00:13.2<br>
> [    1.795899] DMAR: Hardware identity mapping for device 0000:00:13.3<br>
> [    1.795902] DMAR: Hardware identity mapping for device 0000:00:15.0<br>
> [    1.795904] DMAR: Hardware identity mapping for device 0000:00:1f.0<br>
> [    1.795906] DMAR: Hardware identity mapping for device 0000:00:1f.1<br>
> [    1.795911] DMAR: Hardware identity mapping for device 0000:01:00.0<br>
> [    1.795916] DMAR: Hardware identity mapping for device 0000:03:00.0<br>
> [    1.795917] DMAR: Setting RMRR:<br>
> [    1.795920] DMAR: Ignoring identity map for HW passthrough device<br>
> 0000:00:02.0 [0x6f800000 - 0x7fffffff]<br>
> [    1.795922] DMAR: Ignoring identity map for HW passthrough device<br>
> 0000:00:15.0 [0x6d5af000 - 0x6d5cefff]<br>
> [    1.795924] DMAR: Prepare 0-16MiB unity mapping for LPC<br>
> [    1.795926] DMAR: Ignoring identity map for HW passthrough device<br>
> 0000:00:1f.0 [0x0 - 0xffffff]<br>
> [    1.795954] DMAR: Intel(R) Virtualization Technology for Directed I/O<br>
> [    1.796125] iommu: Adding device 0000:00:00.0 to group 0<br>
> [    1.796140] iommu: Adding device 0000:00:02.0 to group 1<br>
> [    1.796157] iommu: Adding device 0000:00:0e.0 to group 2<br>
> [    1.796174] iommu: Adding device 0000:00:0f.0 to group 3<br>
> [    1.796187] iommu: Adding device 0000:00:12.0 to group 4<br>
> [    1.796229] iommu: Adding device 0000:00:13.0 to group 5<br>
> [    1.796254] iommu: Adding device 0000:00:13.1 to group 5<br>
> [    1.796271] iommu: Adding device 0000:00:13.2 to group 5<br>
> [    1.796288] iommu: Adding device 0000:00:13.3 to group 5<br>
> [    1.796317] iommu: Adding device 0000:00:15.0 to group 6<br>
> [    1.796338] iommu: Adding device 0000:00:1f.0 to group 7<br>
> [    1.796350] iommu: Adding device 0000:00:1f.1 to group 7<br>
> [    1.796361] iommu: Adding device 0000:01:00.0 to group 5<br>
> [    1.796371] iommu: Adding device 0000:03:00.0 to group 5<br>
> [    2.512432] ata1.00: supports DRM functions and may not be fully<br>
> accessible<br>
> [    2.514160] ata1.00: supports DRM functions and may not be fully<br>
> accessible<br>
> [    3.124755] VFIO - User Level meta-driver version: 0.3<br>
> [    3.137417] vfio-pci 0000:00:02.0: vgaarb: changed VGA decodes:<br>
> olddecodes=io+mem,decodes=io+<wbr>mem:owns=io+mem<br>
> [    3.156196] vfio_pci: add [8086:5a85[ffff:ffff]] class 0x000000/00000000<br>
> [    3.176202] vfio_pci: add [8086:5a98[ffff:ffff]] class 0x000000/00000000<br>
><br>
> with these entries added when running the VM:<br>
><br>
> [   49.439866] vfio_cap_init: 0000:00:0e.0 pci config conflict @0x80, was<br>
> cap 0x9 now cap 0x10<br>
> [   49.439869] vfio_cap_init: 0000:00:0e.0 pci config conflict @0x81, was<br>
> cap 0x9 now cap 0x10<br>
> [   49.439871] vfio_cap_init: 0000:00:0e.0 pci config conflict @0x82, was<br>
> cap 0x9 now cap 0x10<br>
> [   49.439873] vfio_cap_init: 0000:00:0e.0 pci config conflict @0x83, was<br>
> cap 0x9 now cap 0x10<br>
> [   49.442695] DMAR: DRHD: handling fault status reg 3<br>
> [   49.442710] DMAR: [DMA Write] Request device [00:02.0] fault addr 0<br>
> [fault reason 02] Present bit in context entry is clear<br>
> [   49.567831] vfio_ecap_init: 0000:00:02.0 hiding ecap 0x1b@0x100<br>
><br>
> Passthrough still doesn't work though, and the last two lines in the kernel<br>
> log seem to hint at that. So from option one to option 2:<br>
<br>
</div></div>Nope, those are normal.<br>
<span class=""><br>
> 2) "don't blacklist i915, let the kernel boot with it, then do a 'virsh<br>
> nodedev-detach pci_0000_00_02_0' at boot before starting the VM so that<br>
> you're not binding it back to i915 after every instance of running the<br>
> VM."<br>
><br>
> So I unblacklisted i915 an executed 'virsh nodedev-dettach<br>
> pci_0000_00_02_0':<br>
><br>
> virsh nodedev-dettach pci_0000_00_02_0<br>
> Device pci_0000_00_02_0 detached<br>
><br>
> Then ran the VM. Unfortunately, results are the same, as are the log<br>
> entries in the kernel log (see above).<br>
><br>
> When running the same virsh 'nodedev-dettach pci_0000_00_02_0' command when<br>
> running the VM, I get:<br>
><br>
> virsh nodedev-dettach pci_0000_00_02_0<br>
> error: Failed to detach device pci_0000_00_02_0<br>
> error: Requested operation is not valid: PCI device 0000:00:02.0 is in use<br>
> by driver QEMU, domain ubuntu16.04_desktop<br>
><br>
> So it does seem to be attached to the VM correctly.<br>
><br>
> Maybe interesting observation: when the host boots, the screen shows grub<br>
> and then goes black but stays powered on. When I launch the VM, the screen<br>
> stays black but powers off.<br>
<br>
</span>I think either mechanism above is equally effective and the remaining<br>
pieces is likely that there's no VGA BIOS to initialize the graphics<br>
because the host is running in UEFI mode.  To solve this, burn some<br>
sort of Linux live CD/DVD image and temporarily set the host BIOS to<br>
boot into CSM/legacy mode to that live image.  Sometimes you'll be able<br>
to select between a UEFI or legacy mode booting the CD or you might be<br>
able to prioritize legacy over UEFI, it depends on the system.  Once<br>
you've booted the image, dump the ROM for the IGD to a file and copy it<br>
somewhere that you'll be able to get to it later.  Undo any settings<br>
for booting the image and then look at my rom-fixer utility:<br>
<br>
<a href="https://github.com/awilliam/rom-parser" rel="noreferrer" target="_blank">https://github.com/awilliam/<wbr>rom-parser</a><br>
<br>
Run that on the ROM and then add a <rom file='/path/to/vga.rom'/> to<br>
the IGD hostdev entry in the xml.<br>
<span class=""><br>
> Finally, until now I had ignored the errors in the kernel log on the audio<br>
> device (0000:00:0e.0) as I was focusing on the gpu. As requested, in [2]<br>
> the output of 'sudo lspci -xxxxs 0000:00:0e.0'.<br>
><br>
</span>Thanks, I'll take a look at this.<br>
<span class="HOEnZb"><font color="#888888"><br>
Alex<br>
</font></span></blockquote></div><br></div>