On Fri, 2019-06-14 at 09:42 +0200, Ard Biesheuvel wrote: > The original purpose was for firmware running on 64-bit hosts to not > create a PCI resource assignment that was incompatible with the OS > booting in 32-bit mode. > > So the expectation was that a 32-bit OS would reuse whatever config > the firmware created, and the 64-bit version would be enlightened to > understand that it could reassign resource assignments to make better > use of the available resource windows, but this required a mechanism > to describe which resources should be left alone by the OS. > > So I don't think anybody cares about that use case anymore, and I have > no idea how widespread its use was when people did. Ok. At least my thinkpad happily assigns stuff in 64-bit space. AFAIK even 32-bit distros can deal with it with PAE no ? > > - The "probe only" method. This was created independently on powerpc > > and some other archs afaik. At least for powerpc, the reason for that > > is some interesting virtualization cases where we just cannot touch or > > change or move anything. The effect is to not reassign even what we > > dont like, and not call pci_assign_unassign_resources(). > > > > - The "reassign everything" method. This is used by almost all > > embedded patforms accross archs. All arm32, all arm64 today (but we > > agree that's wrong), all embedded powerpc etc... This is basically > > meant for us not trusting whatever random uboot or other embedded FW, > > if any, and do a full from-scratch assignment. There are issues in how > > that is implemented accross the various platforms/archs, some for > > example still honor existing bus numbers and some don't, but I doubt > > it's intentional etc... but that method is there to stay. > > > > Now, the questions are two fold > > > > - How do we map _DSM #5 to these, at least on arm64, maybe in the > > long run we can also look at affecting x86, but that's less urgent. > > > > - How do I ensure the above fixes my Amazon platform ? :-) > > > > It would help if you could explain what exactly is wrong with your > Amazon platform :-) 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. 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. We want to honor _DSM #5 = 0, and at least initially, leave the rest alone. Now, we *also* want to look at switching the rest to the "normal" (for ACPI platforms at least) mechanism of using what FW setup and fixing up if necessary, but that's not what the code does today, we know just switching to pci_bus_claim_resources() will break some platforms, and we need more testing and possibly quirks to get there, so it's material for a separate patch. But in the meantime, I need to differenciate. Also using "probe_only" for _DSM #5 = 0 isn't a good idea, at least as implemented today in the rest of the kernel, probe_only also means we shouldn't assign what was left unassigned. However _DSM #5 allows this. So we'll need to find some more subtle way to convey these. Bjorn: At this point, because of all the above, I'm keen on going back to my original patch (slightly modified Ard's patch), possibly rewording a thing or two and addressing Lorenzo comment. We can look at a better and more generic implementation of _DSM #5 including for child nodes after I have consolidated more of the resource management code. 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. Cheers, Ben.
