[Bug 235876] ACPI related commit r330113 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

--- Comment #7 from John Baldwin <jhb at FreeBSD.org> ---
So this ASL is definitely using the flag explicitly.  None of them are in
ExtendedAddressSpaces, and some of them appear to be correct (e.g. the Host-PCI
bridge is using ResourceProducer in the way the non-arm-specific ACPI Host-PCI
bridge driver expects: to list ranges it decodes that are then used by child
devices).  It seems that a couple of the uses of ResourceProducer in this ASL
are just wrong though.  First, numbers of times the flag is used vs not used:

> grep ResourceConsumer tx2.asl  | wc -l
      53
> grep ResourceProducer tx2.asl  | wc -l
      11

Of those 11 cases, SB.ECAM is probably a consumer, not a producer, though we
already treat acpi_sysres devices special.

SB.PCI0 resources should be producers.  If the committed patch actually worked
fully it would have broken booting completely since PCI0 would have claimed all
the resources for all its children blocking all of them from being able to
alloc bars.  We probably skip resources for PCI bridges which is why this might
still be working.

The URT0 device's memory should be a consumer.  Note that the interrupt
resource is a consumer, and other similar devices use consumer.  This is just
firmware writer incompetence.

URT1, URT2, and URT3 are same as URT0.

PCI1 is same as PCI0.

So really, the real issue on the Cavium box is that the UART _CRS buffers have
a typo.  I think the commit should be changed so that we just ignore
'ResourceProducer' on devices with the ARMH0011 _HID but otherwise leave it in
place.

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