On Mon, Feb 10, 2020 at 11:17:34AM +0000, Andrew Cooper wrote:
> On 10/02/2020 08:55, Jan Beulich wrote:
> > On 10.02.2020 00:06, Marek Marczykowski-Górecki wrote:
> >> Hi,
> >>
> >> Multiple Qubes users have reported issues with resuming from S3 on AMD
> >> systems (Ryzen 2500U, Ryzen Pro 3700U, maybe more). The error message
> >> is:
> >>
> >> (XEN) CPU0: cap[ 1] is 7ed8320b (expected f6d8320b)
> >>
> >> If I read it right, this is:
> >>   - OSXSAVE: 0 -> 1
> >>   - HYPERVISOR: 1 -> 0
> >>
> >> Commenting out the panic on a failed recheck_cpu_features() in power.c
> >> makes the system work after resume, reportedly stable. But that doesn't
> >> sounds like a good idea generally.
> >>
> >> Is this difference a Xen fault (some missing MSR / other register
> >> restore on resume)? Or BIOS vendor / AMD, that could be worked around in
> >> Xen?
> > The transition of the HYPERVISOR bit is definitely a Xen issue,
> > with Andrew having sent a patch already (iirc).
> 
> https://lore.kernel.org/xen-devel/20200127202121.2961-1-andrew.cooper3@citrix.com/
> 
> Code is correct.  Commit message needs rework, including in light of
> this discovery.  (I may eventually split it into two patches.)

Claudia, do you want to test with this patch?

> > The OSXSAVE part is a little more surprising,
> 
> Not to me.  The checks only care if feature bits have gone missing, not
> if new ones have appeared.
> 
> mmu_cr4_features includes OSXSAVE (from much later on boot than features
> get cached), so the s3 path observing the gain of OSXSAVE will have been
> happening ever since the checks were introduced (even on Intel.)

Is "x86: store cr4 during suspend/resume" patch from Roger related to
this?

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?