AW: Windows DomU: PCIe passthrough issues

[Paul Leiber <paul@xxxxxxxxxxxxxxxx>]

> Von: Paul Leiber
> Gesendet: Montag, 24. Mai 2021 22:39
> 
> after getting my Windows Server 2012 DomU up and running, I have
> problems with reliably passing through my PCIe TV tuner card (Hauppauge
> HVR-2205).

Further testing has lead me to the suspicion that there is an incorrect 
behavior, possibly a bug. It seems that every time I do a _reboot_ from within 
the Windows DomU, the PCI device does not get attached to the DomU. It is 
immediately available for attachment in the Dom0 when I check for it, and I can 
reattach it to the DomU with "xl pci-attach" without any problems. Besides the 
effect that the tuner card gets assigned a new instance number in my TV 
software and I therefore need to reapply some settings in this software, the 
card works normally.

If I _shut down_ the DomU from within the DomU (with Windows shutdown 
mechanism) or the Dom0 (with "xl shutdown) and restart the DomU with "xl 
create", the PCIe device gets attached automatically at DomU boot and the above 
mentioned side effects (new instance number, reapply software settings) do not 
occur.

I could reproduce this behavior with a different TV tuner card from another 
manufacturer, so it seems unlikely that it is related to the specific devices I 
am using.

> The boot entry has the following parameters:
> dom0_mem=1024M,max:1024M xen-pciback.hide=(01:00.0)

I figured out that giving kernel boot option " xen-pciback.hide" is not 
necessary as the driver is not built into the kernel, therefore I changed the 
parameters to:
dom0_mem=1024M,max:1024M

The device is assigned to xen-pciback via /etc/modprobe.d/xen-pciback.conf 
(there is no driver on the Dom0 for the tuner card, therefore no precautions 
for not loading other drivers are necessary, I think):
options xen-pciback hide=(0000:01:00.0)

While doing trial and error, I changed the pci line in the Xen config file to:

pci=['01:00.0,permissive=1,power_mgmt=1,seize=1']

But adding "seize=1" didn't change anything.

> Logs from /var/log/xen, dmesg and /var/log/messages and Windows DomU
> didn't seem to show relevant errors, but can of course be provided if
> needed.

Checking the xl logs more thoroughly, I now found the following lines:

Waiting for domain matrix (domid 8) to die [pid 3113]
Domain 8 has shut down, reason code 1 0x1
Action for shutdown reason code 1 is restart
libxl: warning: libxl_domain.c:1739:libxl_retrieve_domain_configuration: Domain 
8:Device present in JSON but not in xenstore, ignored
Domain 8 needs to be cleaned up: destroying the domain
Done. Rebooting now

Searching for this exact error message, I found the following quite old bug 
report which sounds suspiciously similar to my experience, only for PV DomUs:
https://bugzilla.redhat.com/show_bug.cgi?id=233801

1. Is it possible that this bug is still existing in my rather recent "out of 
the box" debian setup?
release                : 4.19.0-14-amd64
version                : #1 SMP Debian 4.19.171-2 (2021-01-30)
xen_version            : 4.11.4

2. Do you have any idea what I should do now? Any more testing I could do? 
Should I mention this in the Xen developer mailing list? File a bug report 
somewhere (where?)?

I appreciate any advice.

Best regards,

Paul