wrote on 4/6/19 7:14 AM:

This issue is due to a xen patch ("Fix resume, when using microcode upgrade"), 
that has been included when releases changed from xen-4.8.3-4 to xen-4.8.3-5. This patch 
checks the availability of previous CPU features (..Spectre) during resume, and results 
in a xen panic on G505s - IMHO due to the static nature how the most recent (0x600111f) 
AMD microcodes need to be compiled in Corebooted systems.
It is no use to revert the whole patch, because it'll break the other xen 
patches introduced since. But you can:

diff -ur a/xen/arch/x86/acpi/power.c b/xen/arch/x86/acpi/power.c
--- a/xen/arch/x86/acpi/power.c 2019-03-31
+++ b/xen/arch/x86/acpi/power.c 2019-03-31
@@ -256,9 +256,9 @@
microcode_resume_cpu(0); - if ( !recheck_cpu_features(0) )
+/*    if ( !recheck_cpu_features(0) )
          panic("Missing previously available feature(s).");
      /* Re-enabled default NMI/#MC use of MSR_SPEC_CTRL. */
      ci->spec_ctrl_flags |= (default_spec_ctrl_flags & SCF_ist_wrmsr);

have this workaround, which solves the issue until someone provides a working 
solution on CB'd systems with AMD Fam15h. (..and also assesses the possible 
security impacts...)
Of course you'll need to recompile git:qubes-vmm-xen, but that is 
There could be some strange kernel messages in dom0 after resume, and you might 
have issues in sys-net devices waking up, but this mostly works fine (with kernel 
4.14.103 --> kernels 4.19-xx still have issues with the radeon module)

Thank you, I will definitely try it out and report back here! Any idea if someone has submitted upstream to Xen? Seems like it would be an issue with any Corebooted AMD AGESA system since they all handle microcode the same way.

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 post to this group, send email to
To view this discussion on the web visit
For more options, visit

Reply via email to