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

[Z M <zachm1996@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3184 bytes --]

Sorry to bump this ancient issue.. Claudia, did you try the RPMs out, or
did anyone else? I've had xen* and python*-xen excluded from yum/dnf for a
while on my R4.0 so I'm not getting patches on the Xen 4.8 branch. I guess
we need to wait til R4.1 to use it in production as it's built for Xen 4.13
though. Unless there's some way to put Xen 4.13 on R4.0 safely.



On Tue, Feb 11, 2020 at 10:20 PM Claudia <claudia1@disroot.org> wrote:

> February 11, 2020 9:09 PM, "Marek Marczykowski-Górecki" <
> marmarek@invisiblethingslab.com> wrote:
>
> > On Tue, Feb 11, 2020 at 12:59:22PM +0000, Claudia wrote:
> >
> >> February 10, 2020 12:14 PM, "Marek Marczykowski-Górecki" <
> marmarek@invisiblethingslab.com> wrote:
> >>
> >> 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?
> >>
> >> I'm getting hunk failed in domctl.c applying to R4.1 default repo
> (fc31, Xen 4.13). I'll see if I
> >> can fix it but bear with me, I'm new at this.
> >>
> >> Marek: Would you by any chance be willing to merge this into a test
> branch on your repo, so the
> >> rest of us can pull it directly into qubes-builder? It'll take you a
> fraction of the time it'll
> >> take me, plus then zachm and awokd and anyone else can pull it also.
> >
> > Here is one for Xen 4.13:
> > https://github.com/QubesOS/qubes-vmm-xen/pull/71
> > builder.conf snippet for qubes-builder:
> >
> > BRANCH_vmm_xen=xen-4.13-amd-suspend
> > GIT_URL_vmm_xen=https://github.com/marmarek/qubes-vmm-xen
> >
> > This is already v2 patch from the other thread.
>
> Thanks! For anyone else trying this, I also had to add NO_CHECK=vmm-xen
> vmm-xen-stubdom-legacy, I guess because there are no tags on that branch.
> The RPMs built successfully, and I'll be able to test them as soon as I get
> the latest R4.1 build downloaded and installed (I'm currently running 4.0).
>


-- 
- - - - - -
Zachary Muller
http://muller.is/

[-- Attachment #2: Type: text/html, Size: 4550 bytes --]