On 20/11/2024 10:44 am, Jan Beulich wrote: > On 19.11.2024 22:57, Andrew Cooper wrote: >> Resolve the todo, and move microcode loading to be the eariest action after >> establishing a console. > So yes, this is merely strengthening a dependency we already have: > bootstrap_map_addr() arranging to avoid allocating any page table memory. > Yet don't we rather need to move away from this? We don't know what's in > the excess space we map, and hence we better wouldn't have any (cachable) > mappings thereof.
I don't see it this way. Yes it is somewhat dodgy that bootstrap_map*() blindly uses 2M pages. It's a problem with cacheability (in theory at least; TLBs tend to splinter mappings on MTRR mismatch). It's a hard problem with the RMP table (AMD SEV-SNP), where any access into the page yields #PF[Rsvd] if there's any overlap with the RMP (locked in place by firmware and not always 2M aligned). But, any fix to this needs to fix *all* users of bootstrap_map*(), including the move_memory() loop. So I don't see any interaction with how early or late the early-map infrastructure is used. ~Andrew P.S. I have a few ideas on how to address this. With only 2 extra pagetables in .init.bss, we can support any arbitrary single mapping with 4k alignment. move_memory() is the only user that makes multiple mappings, and it's broken anyway. I'm now certain that it does get memmove() wrong if the move has a partial overlap. However, move_memory() always has a good destination pointer in the directmap, so I've got a crazy idea to fix the memmove() problem by also hooking the bootmap into idle_pg_table[511] creating a high alias of the mapping, and the source pointer can choose whichever of the aliases are the correct side of the directmap.
