On 07.11.2024 13:21, Andrew Cooper wrote: > Fold microcode_update_cpu() into its single remaining caller and simplify the > logic by removing the patch != NULL path with microcode_mutex held. > > Explain why we bother grabbing the microcode revision even if we can't load > microcode. > > Furthermore, delete the -EIO path. An error updating microcode on AP boot or > S3 resume is certainly bad, but freeing the cache is about the worst possible > action we can take in response; it prevents subsequent APs from taking an > update they might have accepted.
I'm afraid I disagree here, but I also disagree with the present error handling. -EIO indicates the patch didn't apply. Why would there be any hope that any other CPU would accept it? We're assuming fully symmetric hardware, after all. However, imo it's not -EIO that ought to be special cased, but success and -EEXIST. In all other cases the same error will re-surface for other CPUs. Plus by not cleaning the cache we prevent an older revision to be installed (without forcing its installation). Keeping what's cached might be an option, but then followed by cleaning the cache unless at least one CPU actually accepted the ucode. Jan
