On 06/01/2025 2:41 pm, Jan Beulich wrote: > On 06.01.2025 15:19, Andrew Cooper wrote: >> Fam1Ah is similar to Fam19h in these regards. >> >> Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com> >> --- >> CC: Jan Beulich <jbeul...@suse.com> >> CC: Roger Pau Monné <roger....@citrix.com> >> >> With this patch, I think we're in an ok position to declare support on Zen5 >> CPUs. > What about amd_log_freq(), where the 0x19 upper bound may need bumping?
Ah, that's new since I did Fam19. I'll adjust. > >> --- a/xen/arch/x86/cpu/microcode/amd.c >> +++ b/xen/arch/x86/cpu/microcode/amd.c >> @@ -114,6 +114,7 @@ static bool verify_patch_size(uint32_t patch_size) >> #define F16H_MPB_MAX_SIZE 3458 >> #define F17H_MPB_MAX_SIZE 3200 >> #define F19H_MPB_MAX_SIZE 5568 >> +#define F1AH_MPB_MAX_SIZE 14368 > Yet another pretty odd number. Are these actually documented anywhere? In the PPRs. > And what has come of their plan to make ucode size available via CPUID > (for which I even sent a patch quite a long while ago)? This check in this function need to work for any microcode we find in the container. Knowing the size of the current CPU doesn't help parsing others. And talking of, I've just found another Fam1Ah processor with an even larger patch size. This limit needs bumping to 15296. ~Andrew
