December 23, 2019 7:31 AM, "qubes123" <dm1.libe...@gmail.com> wrote:
> Suspend/resume problem is most likely caused by a recently added security > feature in Xen, that > checks CPUID after resume with the previously (at boot time) known CPUID. > This is to ensure, that > the CPU microcode level - along with the resulting Spectere/Meltdown etc. > mitigations - still > persist after system resume and there are no features missing. > > For many AMD systems (eg. Trinity/Richland) CPUID changes after suspend (some > of the high bits), > resulting in Xen Panic (see xen/arch/x86/acpi/power.c). So, more > investigation would be needed to > check why the CPUID bits are changing after resume and whether it had any > security implications or > not. > For the time being - if you accept the possible security implications - you > can disable that check > eg. by commenting the panic line out after "recheck_cpu_features" in the > above mentioned power.c > file, compile xen for dom0 via qubes builder and test it in your system. So I installed the new F31-based R4.1 with Xen 8.13. Suspend/resume still isn't working; same symptoms as before. A few corrections: I dug up some old threads and found that suspend/resume actually did work correctly in F29, and on F25 the screen would power on, but just remain blank. So in fact I never got the same symptoms on Qubes as I did with Fedora 25. This means that very likely could be a Xen panic. Something new, I booted R4.1 on bare metal without Xen, and it resumes fine. It probably will even under R4.0 without Xen, too, but I haven't tried yet. So apparently it's not a version issue. While booted without Xen, I checked /proc/cpuinfo before and after resume and they were the same except for clock rates. The output is significantly different under Xen than bare metal, but the microcode version is the same. In Xen, I obviously can't compare before- and after-resume outputs. Not sure what to do. I'm really not looking forward to patching Xen. > 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. That kind of makes sense. With your patch applied, can you see the CPUID bits in /proc/cpuid change after resume, or is the output the same as before? Like I said, in my case nothing in /proc/cpuinfo changes before and after resume without Xen (although it could be different under Xen). -- 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/162650f9ca7407a9f96832e27ad1a875%40disroot.org.
