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: b...@freebsd.org
Reporter: w...@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.
_______________________________________________
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
