On Monday, December 23, 2019 at 7:51:33 AM UTC, Vít Šesták wrote:
>
> Qubes123, that's an interesting finding. AFAIU, the CPUID check is rather 
> a sanity check – it verifies that the microcode is loaded properly. I also, 
> this should be no issue if Qubes provides a fresh microcode…
>
> (And maybe it can cause crash if you suspend after BIOS update, provided 
> that the BIOS contains a newer microcode.)
>
> Regards,
> Vít Šesták 'v6ak'


I use a Corebooted system, where the latest AMD microcode is compiled into 
the BIOS statically.  And yes, I use a newer version of the AMD Fam15h 
microcode, than the version in the Linux Firmware package.
This change in some of the CPUID bits after resume could be a result of 
xen/kernel trying to load the published microcode, and then fails because 
the BIOS version is newer.
However, the /proc/cpuinfo reported microcode version always stays the same 
- the BIOS version. (..assuming the /proc/cpuinfo output is updated on any 
microcode upgrade attempts..)

As noted, I have a "special" use case, so testing the recommended change in 
power.c for Claudia's newer AMD system could show, that this CPUID change 
issue after resume is "special" for my case or "general" for some AMD users.

BR,
Qubes123
  

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/5389938b-69f2-4f58-bdc3-b18c5c059cf7%40googlegroups.com.

Reply via email to