On Fri, Jun 14, 2019 at 06:36:32PM +1000, Benjamin Herrenschmidt wrote: > Linux can't change the switch configuration. I may have mentioned > earlier it has to do with platform sec policies. But that's not totally > relevant, we shoudn't be changing resources anyway since in theory > runtime FW might rely on where some system devices were assigned at > boot. EFI fb is another example of that. "We shouldn't be changing resources anyway" is not really useful guidance. I completely agree that we shouldn't change things *unnecessarily*, but it's up to the OS to define what makes it necessary -- it might be for rebalancing for hotplug, to make space for SR-IOV, to respect user requests to increase alignment, etc. IMO the real value of _DSM #5 is as a mechanism to advertise dependencies runtime firmware has on devices, e.g., SMM firmware might want to log errors to a PCI remote management device. If the OS moved that managment device, the SMM logging would itself cause errors. > The biggest issue for me right now is that the spec says pretty much at > _DSM #5 = 0 is equivalent to _DSM #5 absent, and Bjorn seems keen on > having it this way, but for arm64, we specifically want to distinguish > those 2 cases. Nope, my opinion is exactly the opposite. Sorry that I'm not communicating this clearly. It's true that the r3.2 spec *does* say _DSM #5 = 0 is equivalent to the situation where it's absent, but that's based on the assumption that the OS is never allowed to change PCI configuration. I think that assumption is complete nonsense and should be disregarded. _DSM #5 = 0: OS must preserve this device's BARs (current spec says "OS must not ignore") _DSM #5 = 1: OS *may* change this device's BARs (current spec says "OS may ignore") Other than _DSM #5, there's no spec I'm aware of that restricts the OS's ability to change BARs. Therefore I think "_DSM #5 = 1" is equivalent to _DSM #5 being absent, and in both cases the OS is free to change BARs as it sees fit. > Looking at the spec (and followup discussions for specs updates), I'm > quite keen on treating _DSM #5 = 1 as "wipe out the resource for that > endpoint/bridge and realloc something better. There are reasons for > that, but we can probably discuss that later. I disagree on the "wipe out all resources" part of this because we have no idea how to realloc something better. We should of course look for problems (overlapping devices, etc) and fix them. But starting from scratch and reallocating won't reliably produce anything different from the original, supposedly broken, configuration. Bjorn
