[Pkg-xen-devel] Bug#988333: linux-image-5.10.0-6-amd64: VGA Intel IGD Passthrough to Debian Xen HVM DomUs not working, but Windows Xen HVMs do work

[Chuck Zmudzinski]

> On 10/23/2021 11:11 AM, Hans van Kranenburg wrote:
>>
>> Can you share the domU config file?
>
> Yes, here it is:
>
> builder = 'hvm'
> memory = '3072'
> vcpus = '4'
> device_model_version = 'qemu-xen'
> # device_model_version = 'qemu-xen-traditional'
> # This is now bullseye
> disk = ['/dev/systems/linux,,xvda,w','/dev/data/linuxdata,,xvdb,w']
> name = 'bullseye-hvm'
> vif = [ 
> 'mac=00:16:3E:27:2C:AA,model=e1000,script=vif-route.hvm,ip=192.168.1.4' ]
> on_poweroff = 'destroy'
> on_reboot = 'restart'
> on_crash = 'restart'
> boot = 'c'
> acpi = '1'
> apic = '1'
> viridian = '1'
> xen_platform_pci = '1'
> serial = 'pty'
> vga = 'none'
> sdl = '0'
> vnc = '0'
> gfx_passthru = '1'
> pci = [ '00:1b.0', '00:14.0,rdm_policy=relaxed', '00:02.0' ]
>
>>
>> And, other configs you need to have in place to exclude the devices from
>> being seen as normal devices directly in dom0? (I haven't used
>> passthrough myself yet, but I read that this is needed.)
>
> I run this script in Dom0 before starting the domain:
>
> #!/bin/bash
> modprobe xen-pciback
> xl pci-assignable-add 00:02.0
> xl pci-assignable-add 00:14.0
> xl pci-assignable-add 00:1b.0
> xl pci-assignable-list
>
> The script makes the Intel IGD, USB 3.0 controller, and
> sound device available to an unprivileged domain. the pci = ...
> statement in the domain config corresponds to these same
> three PCI devices.

I forgot to add that you need to run lspci in dom0 to get the
PCI bus, slot and function numbers of the PCI devices you want to
pass through to the unprivileged domain. On my system,
this is what I got:

$lspci
00:00.0 Host bridge: Intel Corporation 4th Gen Core Processor DRAM 
Controller (rev 06)
00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3/4th 
Gen Core Processor Integrated Graphics Controller (rev 06)
00:03.0 Audio device: Intel Corporation Xeon E3-1200 v3/4th Gen Core 
Processor HD Audio Controller (rev 06)
00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset 
Family USB xHCI (rev 05)
00:16.0 Communication controller: Intel Corporation 8 Series/C220 Series 
Chipset Family MEI Controller #1 (rev 04)
00:19.0 Ethernet controller: Intel Corporation Ethernet Connection 
I217-V (rev 05)
00:1a.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset 
Family USB EHCI #2 (rev 05)
00:1b.0 Audio device: Intel Corporation 8 Series/C220 Series Chipset 
High Definition Audio Controller (rev 05)
00:1c.0 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset 
Family PCI Express Root Port #1 (rev d5)
00:1c.3 PCI bridge: Intel Corporation 82801 PCI Bridge (rev d5)
00:1c.4 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset 
Family PCI Express Root Port #5 (rev d5)
00:1d.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset 
Family USB EHCI #1 (rev 05)
00:1f.0 ISA bridge: Intel Corporation B85 Express LPC Controller (rev 05)
00:1f.2 SATA controller: Intel Corporation 8 Series/C220 Series Chipset 
Family 6-port SATA Controller 1 [AHCI mode] (rev 05)
00:1f.3 SMBus: Intel Corporation 8 Series/C220 Series Chipset Family 
SMBus Controller (rev 05)
02:00.0 PCI bridge: ASMedia Technology Inc. ASM1083/1085 PCIe to PCI 
Bridge (rev 04)
04:00.0 Network controller: Qualcomm Atheros AR9287 Wireless Network 
Adapter (PCI-Express) (rev 01)

The PCI slot and function numbers might be different for the USB
controller and sound card on other systems, but it is always 00:02.0
for the Intel IGD from what I have read. On my system, from the output
of lspci listed above the USB 3.0 controller (xHCI as opposed to EHCI
which indicates an older and slower USB 2.0 controller) is 00:14.0
and the sound card is 00:1b.0, and this is where the arguments for the
pci = ... statement in the domU config file and the xl pci-assignable-add
commands come from.

Also, it was necessary to add the rdm_policy=relaxed option to the USB
card in the pci = statement, and YMMV with different hardware as far
as how compatible your PCI devices are with PCI passthrough. From what
I have read, the relaxed rdm_policy setting is needed because my USB
card's memory overlaps with other devices, and I think Intel does a
better job isolating the PCI devices with newer hardware. My box is
now almost seven years old and I think newer hardware might not
need that relaxed rdm_policy setting. It would be better to have hardware
that works without this relaxed rdm_policy because allowing passthrough
of devices that overlap with other devices' memory is obviously a
security concern, but my setup does not involve any untrusted domains
so I am comfortable using it in my environment.

All the best,

Chuck