On Sun, Feb 4, 2024 at 6:21 PM Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: > On Fri, Feb 2, 2024 at 12:08 AM Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: > > On Thu, Feb 1, 2024 at 7:29 PM Dave Hansen <dave.hansen@xxxxxxxxx> wrote: > > > I really wanted get_cpu_address_sizes() to be the one and only spot > > > where c->x86_phys_bits is established. That way, we don't get a bunch > > > of code all of the place tweaking it and fighting for who "wins". > > > We're not there yet, but the approach in this patch moves it back in the > > > wrong direction because it permits the random tweaking of c->x86_phys_bits. > > > > There is unfortunately an important hurdle [...] in that > > currently the BSP and AP flows are completely different. For the BSP > > the flow is ->c_early_init(), then get_cpu_address_sizes(), then again > > ->c_early_init() called by ->c_init(), then ->c_init(). For APs it is > > get_cpu_address_sizes(), then ->c_early_init() called by ->c_init(), > > then the rest of ->c_init(). And let's not even look at > > ->c_identify(). [...] get_cpu_address_sizes() > > is called too early to see enc_phys_bits on APs. But it was also > > something that fbf6449f84bf didn't take into account, because it left > > behind the tentative initialization of x86_*_bits in identify_cpu(), > > while removing it from early_identify_cpu(). And Ping, either for applying the original patches or for guidance on how to proceed. Paolo
