Re: [Xen-devel] Xen fails to resume on AMD Fam15h (and Fam17h?) because of CPUID mismatch - Marek Marczykowski-Górecki

From: "Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>,
	Claudia <claudia1@disroot.org>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
	zachm1996@gmail.com, Jan Beulich <jbeulich@suse.com>
Subject: Re: [Xen-devel] Xen fails to resume on AMD Fam15h (and Fam17h?) because of CPUID mismatch
Date: Mon, 10 Feb 2020 13:14:43 +0100	[thread overview]
Message-ID: <20200210121443.GQ7869@mail-itl> (raw)
In-Reply-To: <41b3896b-5414-bfdf-a515-bf2f06ab6463@citrix.com>

[-- Attachment #1.1: Type: text/plain, Size: 1934 bytes --]

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?

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel