[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-users] xl create failures w/ Intel IGU passthrough

Hello list,

Getting failures to create Win7 HVM using Intel HD4xxx IGU passthrough with the following in /var/log/xen/qemu-dm-win7-hvm.log:

  [00:05.0] xen_pt_initfn: Error: Need to enable igd-passthru if you're trying to passthrough IGD GFX. 

...xl.cfg manpage (https://xenbits.xen.org/docs/unstable/man/xl.cfg.5.html) doesn't reference this feature nor does it seem to do anything when used in xen. Don't see anything about it in the qemu manpage (https://www.systutorials.com/docs/linux/man/1-qemu/) This same system has succesfully passed a Radeon HD 5570 on another DomU. Have been running each one-at-a-time with hypervisor reboot between each.

Used the same blacklisting i915/pciback binding for the IGU on device 00:02.0, confirmed in lspci to be bound to pciback:
00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller (rev 06) (prog-if 00 [VGA controller])
DeviceName:  CPU
Subsystem: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller
Flags: fast devsel, IRQ 16
Memory at f7800000 (64-bit, non-prefetchable) [disabled] [size=4M]
Memory at d0000000 (64-bit, prefetchable) [disabled] [size=256M]
I/O ports at f000 [disabled] [size=64]
Expansion ROM at <unassigned> [disabled]
Capabilities: <access denied>
Kernel driver in use: pciback
Kernel modules: i915
Came to the understanding that IGUs should be passed to the virtual slot 2 as the drivers tend to assume them to be there (http://vfio.blogspot.com/2016/07/intel-graphics-assignment.html), but when attempting:


... startup failed with:

PCI: slot 2 function 0 not available for xen-pci-passthrough, in use by xen-platform

... disabling xen_platform_pci resulted in another failure:

libxl: error: libxl_qmp.c:287:qmp_handle_error_response: received an error message from QMP server: PCI: slot 2 function 0 not available for xen-pci-passthrough, in use by VGA

...tried again by disabling the VGA virtual device used for VNC and it gave the same failure but with the RTL audio device taking slot 2, etc etc etc.. At this point it became obvious that qemu was giving assignment priority to automatically-allocated virtual devices over the explicitly-defined passthrough devices given in the xl DomU config file and continued efforts would be fruitless.

Attempting to use gfx_passthru=1 in DomU config with vga="none" results in following failure:
libxl: error: libxl_dm.c:1872:device_model_spawn_outcome: domain 30 device model: spawn failed (rc=-3)
libxl: error: libxl_create.c:1344:domcreate_devmodel_started: device model did not start: -3
... /var/log/xen/qemu-dm-win7-hvm.log contained this:

    qemu-system-i386: -gfx_passthru: invalid option

Based on experiences shared here (https://lists.gt.net/xen/users/290284) I attempted the line:
device_model_version="qemu-xen-traditional" but got the following failure:
libxl: error: libxl_dm.c:1724:libxl__spawn_local_dm: device model /usr/lib/xen-4.6/bin/qemu-dm is not executable: No such file or directory
libxl: error: libxl_dm.c:1872:device_model_spawn_outcome: (null): spawn failed (rc=-3)
libxl: error: libxl_create.c:1344:domcreate_devmodel_started: device model did not start: -3
libxl: error: libxl_dm.c:1979:kill_device_model: unable to find device model pid in /local/domain/31/image/device-model-pid
...came across an answer (https://stackoverflow.com/questions/33761738/xen-4-4-usr-lib-xen-4-4-bin-qemu-dm-is-not-executable) but my Dom0's repos do not have qemu-system-x86 available. 

Is the traditional qemu officially obsolete? 
Is this a ubuntu packaging/compiling issue? 
Ideas for getting around these errors? 
Is there reasonable promise that manually compiling/installing a newer Xen or Kernel could alleviate this? (enough promise to justify the risk of failing the Dom0 boot process and having to plug a monitor/keyboard in and repair it?) 
Is there a way to send qemu args directly from the xl DomU config file to make the virtual device assignments explicit?

For context, the hypervisor is a headless system used for automated testing of software against various GPU/OS configurations. The GPUs are loaded with dummy plugs. The Radeon hardware works fine with normal PCI passthrough. I would prefer to keep a virtual VGA device available so that I can VNC into the bootup process because boot failures/recovery interactions do not allow Win7 TightVNC server to run. Info about my Dom0:
Linux 4.4.0-104-generic #127-Ubuntu SMP Mon Dec 11 12:16:42 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

$ sudo xl info
release                : 4.4.0-104-generic
version                : #127-Ubuntu SMP Mon Dec 11 12:16:42 UTC 2017
machine                : x86_64
nr_cpus                : 4
max_cpu_id             : 3
nr_nodes               : 1
cores_per_socket       : 4
threads_per_core       : 1
cpu_mhz                : 2993
hw_caps                : bfebfbff:2c100800:00000000:00007f00:77fafbbf:00000000:00000021:000027ab
virt_caps              : hvm hvm_directio
total_memory           : 16308
free_memory            : 15065
sharing_freed_memory   : 0
sharing_used_memory    : 0
outstanding_claims     : 0
free_cpus              : 0
xen_major              : 4
xen_minor              : 6
xen_extra              : .5
xen_version            : 4.6.5
xen_caps               : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 
xen_scheduler          : credit
xen_pagesize           : 4096
platform_params        : virt_start=0xffff800000000000
xen_changeset          : 
xen_commandline        : placeholder dom0_mem=1G
cc_compiler            : gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
cc_compile_by          : stefan.bader
cc_compile_domain      : canonical.com
cc_compile_date        : Fri Oct 13 15:42:52 UTC 2017
xend_config_format     : 4

Here is (one version of) my domU  .cfg

memory = 2048

# Should be at least 2KB per MB of domain memory, plus a few MB per vcpu.
# shadow_memory = 32
name = "win7-hvm"
vif = [ 'mac=00:16:3e:71:51:ba, type=ioemu, bridge=virbr0' ]

acpi = 1
apic = 1
pae = 1
viridian = 1

disk = [ 'format=raw, vdev=hda, access=rw, target=[redacted].img', ' format=raw, vdev=hdc,  access=r, devtype=cdrom, target=[redacted] ]



# INTEL ONBOARD PCI device 00:02.0 8086:0412

# boot on floppy (a), hard disk (c) or CD-ROM (d) 
# default: hard disk, cd-rom, floppy

# usbdevice=['tablet','host:3.4','host:3.7']

#pci=["00:02.0@02"] #This conflicts with automatically-installed virt devs

Thanks for reading.

Xen-users mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.