On Tue, 2015-08-25 at 19:37 -0700, Andrew Fish wrote: > But it looks like the default in ACPI is a CPU (processor-relative) > address. Thus if the mapping is not 1:1 "Address Translation Offset” > is the offset for the bus view. > > I see from the PCI bus driver that there is not a path to return the > "Address Translation Offset”. It seems like the PCI Root Bridge IO > protocol could return the ""Address Translation Offset”, and the PCI > Bus driver could save that per Bar and then return that value in the > ACPI Address Space Descriptor. Maybe Ben could look into that a > propose a patch if it works.
That would be an option. The main problem with that is that currently the PciBusDxe code seems to be hijacking that field for other purposes but I could look into it. So if I understand things properly: For any ACPI resource descriptor exchange between the root bus driver and the core, the address value is a CPU address and the Address Translation Offset is an offset to apply to obtain the PCI address ? In most cases it's going to be negative, but I assume unsigned 2 -complement arithmetic should work fine here, it will jsut look like an fffff* value. Or is the offset meant to be substracted ? Doing that means that the existing GetBarAttributes() for getting a CPU address usage by drivers will just work. However, any driver using it and expecting a *BAR* value for whatever other purpose would be broken, but that's less of a concern as it is easy to fix (either by applying the offset which we can return as well, or by just reading the BAR directly). I still think we need to clarify this in the UEFI spec however, to make sure everybody is on the same page. From there I can give a try at fixing up PciBusDxe (though it may take me a while, the resource allocation code in there is far from trivial). Cheers, Ben. _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
