On Sun, Feb 9, 2020 at 9:15 AM Claudia <claud...@disroot.org> wrote: > From linuxreviews.org: > "There have been reports of RDRAND issues after resuming from suspend on > some AMD family 15h and family 16h systems. [...] RDRAND support is > indicated by CPUID Fn00000001_ECX[30]. This bit can be reset by clearing > MSR C001_1004[62]. Any software that checks for RDRAND support using CPUID, > including the kernel, will believe that RDRAND is not supported. " > > According to the page below, RDRAND is bit 30 in ECX, not 31. And that > still doesn't explain the 27th bit turning on after resume. > 27: OSXSAVE (turns ON) > 30: RDRAND (unchanged) > 31: Not used, always 0 (turns ON) > > https://www.felixcloutier.com/x86/cpuid#fig-3-7 > > So it doesn't sound like the same problem at all, but all my search > queries seem to lead back to the RDRAND issue. I'm hoping someone with more > expertise in this area can make some better sense of this.
Hmm bit 27 can be influenced by software. Might be an issue where the value was saved for reference before the OS/hypervisor modified it? OSXSAVE A value of 1 indicates that the OS has set CR4.OSXSAVE[bit 18] to enable XSETBV/XGETBV instructions to access XCR0 and to support processor extended state management using XSAVE/XRSTOR > -- 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/CAOajFedfNAM-wo2k7bD4oSWAOrfWfp3J%2BO4pnVHR7nXg3%2BKOCg%40mail.gmail.com.
