[Bug 235876] ACPI related commit r330133 broke Microsoft Hyper-V passthrough device on Generation 2 FreeBSD VM

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235876

            Bug ID: 235876
           Summary: ACPI related commit r330133 broke Microsoft Hyper-V
                    passthrough device on Generation 2 FreeBSD VM
           Product: Base System
           Version: 12.0-RELEASE
          Hardware: amd64
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: kern
          Assignee: bugs at FreeBSD.org
          Reporter: weh at microsoft.com

Created attachment 202178
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=202178&action=edit
Acpidump collected on FreeBSD 12 Guest OS running as a Gen 2 VM on Microsoft
Hyper-V

On HyperV Generation 2 VMs, all passthrough devices are attached to pcib0 bus.
Upon guest OS boot, pcib0 bus as a device asks to resource 0x2000 byte MMIO
memory address space. With the Commit r330133, the request was rejected by
nexus_alloc_resource(). Further debugging shows with this commit, the address
range requested has been reserved by unknown device much earlier than pcib0’s
request. And almost all good addresses were reserved by this ‘unknown’ device.
I put some debug print in the code. Following is the dmesg output:
----
OS boot
…
nexus0: &&&in nexus_alloc_resource, check 10, child request range
(0xfe0000000-0xfffffffff), count 0x20000000     A request to reserve this
amount of memory address in the range.
unknown: &&&in nexus_alloc_resource, check 20, this is the child, needactivate
= 0    requesting child is unknown because the name of device_t is empty.
nexus0: &&&in nexus_alloc_resource, after calling rman_reserve_resource, rv
return Not NULL           memory addr successfully reserved for this unknown
device
…
nexus0: &&&in nexus_alloc_resource, check 10, this is the request bus, range
(0xf8000000-0xffdfffff), count 0x7e00000   once again request another chunk of
memory address
unknown: &&&in nexus_alloc_resource, check 20, this is the child, needactivate
= 0      requesting child is unknown because the name of device_t is empty.
nexus0: &&&in nexus_alloc_resource, after calling rman_reserve_resource, rv
return Not NULL    memory addr successfully reserved again for this unknown
device
…
…
nexus0: &&&in nexus_alloc_resource, check 10, this is the request bus, range
(0xfe0000000-0xfffffffff), count 0x2000    A request to reserve 0x2000 byte in
this address range
pcib0: &&&in nexus_alloc_resource, check 20, this is the child, needactivate =
2       the requestor is pcib0
vmbus0: ***in pcib_host_res_alloc, after calling bus_generic_alloc_resource, r
= NULL      request failed
…
nexus0: &&&in nexus_alloc_resource, check 10, this is the request bus, range
(0xf8000000-0xfed3ffff), count 0x2000    Pcib0 tries again in a different
address range.
pcib0: &&&in nexus_alloc_resource, check 20, this is the child, needactivate =
2        the requestor is pcib0
vmbus0: ***in pcib_host_res_alloc, after calling bus_generic_alloc_resource, r
= NULL      failed again because both of the address ranges were already
reserved by ‘unknown’ device
…
pcib0: failed to get resource for cfg window    picb0 failed to attach, and
hence all passthrough devices attached under this bus fail to attach and load.
----

I did a long binary search on head branch and finally narrow down to this
commit r330113. The commit was not in 11 branch so passthrough on 11.2 VM still
works fine. However 12 release got affected. I suspect this tiny change in ACPI
causes the device address interpretation changed. 

Attached is acpidump output I did on a Hyper-V Gen 2 VM with one NIC configured
to pass through to the VM.

-- 
You are receiving this mail because:
You are the assignee for the bug.