Re: [qubes-users] Re: R4 system requirements; AMD compatibility?
February 9, 2020 8:52 PM, "Marek Marczykowski-Górecki" wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On Sun, Feb 09, 2020 at 09:28:13AM -0800, brendan.h...@gmail.com wrote: >> On Sunday, February 9, 2020 at 5:25:56 PM UTC, brend...@gmail.com wrote: >>> >>> >>> Has anyone tried utilizing the xen command line options to mask bits in >>> the cpuid, in particular section 1.2.35 cpuid_mask_ecx)? >>> >>> The man page below says that "Settings applied here take effect globally, >>> including for Xen and all guests." This *might* mean it is applied *before* >>> the resume from sleep CPU bit checks (but I'm not promising anything, as I >>> have not traced through the source). And also "*Warning: This option is >>> not fully effective on Family 15h processors or later.*" >>> >> >> Just noticed that the warning applies only to 1.2.34, which is AMD-only, >> apparently. Unclear to me if the other items 1.2.35 and higher, which is >> for "x86" apply only to intel or to all x86 architecture. > > I may be missing it in this thread, but have anybody tried Qubes 4.1 > builds (with Xen 4.13) on such system? Does it have the same issue? I also had the same problem with unpatched Xen 4.13, it was on the fc31-based R4.1 build right before christmas. The check was introduced in 4.8.3.3 and probably hasn't changed. For what it's worth, R4.1 and R4.0 both resume fine when booted without Xen. See https://www.mail-archive.com/qubes-users@googlegroups.com/msg31518.html -- 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/874173b083a3c9426f120f68814a9bf7%40disroot.org.
Re: [qubes-users] Re: R4 system requirements; AMD compatibility?
Claudia: >> marmarek: >> For this particular case (microcode included in BIOS newer than in OS), I >> see two options: make >> BIOS (coreboot, right?) apply microcode update on resume too, or include >> newer microcode in OS. > > I want to make one thing clear: I am **not** suggesting this check be removed > altogether. I am suggesting adding an **optional**, even undocumented, > override parameter which defaults to the **current behavior** which is to > panic. > > I've found the patch to be quite stable so far. Unpatched is guaranteed to > cause a crash (xen > panic) at resume; patched so far has not caused any noticeable stability > issues for the four of us > using it, afaik. Just saying. > > Also, not everyone has the option of coreboot. And we're not even completely > certain this a > post-resume microcode update issue, either. FWIW, my corebooted AMD has the same issue and resolution. Of course, much of the source code came from AMD so it could be something common to most/all. I wonder if there's a fix that could be made at that level. -- - don't top post Mailing list etiquette: - trim quoted reply to only relevant portions - when possible, copy and paste text instead of screenshots -- 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/a4dc0396-7404-821e-529f-f63110c0e560%40danwin1210.me.
Re: [qubes-users] Re: R4 system requirements; AMD compatibility?
On Sunday, February 9, 2020 at 2:52:57 PM UTC-6, Marek Marczykowski-Górecki wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On Sun, Feb 09, 2020 at 09:28:13AM -0800, brend...@gmail.com > wrote: > > On Sunday, February 9, 2020 at 5:25:56 PM UTC, brend...@gmail.com > wrote: > > > > > > > > > Has anyone tried utilizing the xen command line options to mask bits > in > > > the cpuid, in particular section 1.2.35 cpuid_mask_ecx)? > > > > > > The man page below says that "Settings applied here take effect > globally, > > > including for Xen and all guests." This *might* mean it is applied > *before* > > > the resume from sleep CPU bit checks (but I'm not promising anything, > as I > > > have not traced through the source). And also "*Warning: This option > is > > > not fully effective on Family 15h processors or later.*" > > > > > > > Just noticed that the warning applies only to 1.2.34, which is AMD-only, > > apparently. Unclear to me if the other items 1.2.35 and higher, which is > > for "x86" apply only to intel or to all x86 architecture. > > I may be missing it in this thread, but have anybody tried Qubes 4.1 > builds (with Xen 4.13) on such system? Does it have the same issue? > > I have, yes. A few days ago I built an ISO using R4.1 and tested it. The same issue happens with a fresh R4.1 install and Xen 4.13 + 5.4 kernel. > - -- > 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? > -BEGIN PGP SIGNATURE- > > iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAl5AcSAACgkQ24/THMrX > 1yzQ/ggAmQOFWyP0GNVs5dMuSzKx6mo7myoJ0tlJaKdpNPKZZnYjaLAqhUPig5YG > rd5iv26TjVq/bl8uiRE0/qwV0/sjqgmLTqPIQanzxsB5Cnok3OZyswghGJY/UY8Y > j5ADzpzRtCC7WhQkvhtPSwcC3c72rgmjfQg2IjKfYU6qyv+0aJ2HuJQj/kA49cG6 > kzwGRIJJlxVfCsnlXSwmHa17PyiolvYqpQFhCN8EIM3KYFcjrBK+kP7nqdNXuQ8R > atZqH66h8wxp/BvGO9xGZPmWV6uhrC+JIKfdlaspKO4fWFxXuBwxGgS+favkn5wT > vBJcU6wxj2Qwk6MvJV17BMV1dwqntg== > =HtGL > -END PGP SIGNATURE- > -- 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/cd0084c5-b049-4357-8b8c-06f9cec3eb18%40googlegroups.com.
Re: [qubes-users] Re: R4 system requirements; AMD compatibility?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sun, Feb 09, 2020 at 09:28:13AM -0800, brendan.h...@gmail.com wrote: > On Sunday, February 9, 2020 at 5:25:56 PM UTC, brend...@gmail.com wrote: > > > > > > Has anyone tried utilizing the xen command line options to mask bits in > > the cpuid, in particular section 1.2.35 cpuid_mask_ecx)? > > > > The man page below says that "Settings applied here take effect globally, > > including for Xen and all guests." This *might* mean it is applied *before* > > the resume from sleep CPU bit checks (but I'm not promising anything, as I > > have not traced through the source). And also "*Warning: This option is > > not fully effective on Family 15h processors or later.*" > > > > Just noticed that the warning applies only to 1.2.34, which is AMD-only, > apparently. Unclear to me if the other items 1.2.35 and higher, which is > for "x86" apply only to intel or to all x86 architecture. I may be missing it in this thread, but have anybody tried Qubes 4.1 builds (with Xen 4.13) on such system? Does it have the same issue? - -- 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? -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAl5AcSAACgkQ24/THMrX 1yzQ/ggAmQOFWyP0GNVs5dMuSzKx6mo7myoJ0tlJaKdpNPKZZnYjaLAqhUPig5YG rd5iv26TjVq/bl8uiRE0/qwV0/sjqgmLTqPIQanzxsB5Cnok3OZyswghGJY/UY8Y j5ADzpzRtCC7WhQkvhtPSwcC3c72rgmjfQg2IjKfYU6qyv+0aJ2HuJQj/kA49cG6 kzwGRIJJlxVfCsnlXSwmHa17PyiolvYqpQFhCN8EIM3KYFcjrBK+kP7nqdNXuQ8R atZqH66h8wxp/BvGO9xGZPmWV6uhrC+JIKfdlaspKO4fWFxXuBwxGgS+favkn5wT vBJcU6wxj2Qwk6MvJV17BMV1dwqntg== =HtGL -END PGP SIGNATURE- -- 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/20200209205248.GD29736%40mail-itl.
Re: [qubes-users] Re: R4 system requirements; AMD compatibility?
On Sunday, February 9, 2020 at 5:25:56 PM UTC, brend...@gmail.com wrote: > > > Has anyone tried utilizing the xen command line options to mask bits in > the cpuid, in particular section 1.2.35 cpuid_mask_ecx)? > > The man page below says that "Settings applied here take effect globally, > including for Xen and all guests." This *might* mean it is applied *before* > the resume from sleep CPU bit checks (but I'm not promising anything, as I > have not traced through the source). And also "*Warning: This option is > not fully effective on Family 15h processors or later.*" > Just noticed that the warning applies only to 1.2.34, which is AMD-only, apparently. Unclear to me if the other items 1.2.35 and higher, which is for "x86" apply only to intel or to all x86 architecture. B -- 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/4e3833ec-12e9-4f12-a128-52d449ec336d%40googlegroups.com.
Re: [qubes-users] Re: R4 system requirements; AMD compatibility?
On Sunday, February 9, 2020 at 3:19:34 PM UTC, Claudia wrote: > > > marmarek: > > This is a very bad idea to "fix" it. Those missing/changed CPUID bits > later on will cause issues. > > And given most of the microcode updates recently are about speculative > execution, missing those > > features will make the host vulnerable to those issues again. There are > multiple ways it can > > manifest - from crashes when Xen uses (now not present) CPU feature, to > silent failures when Xen > > tries to use some feature and assume it protects the system, while it > does not in practice. > > > > For this particular case (microcode included in BIOS newer than in OS), > I see two options: make > > BIOS (coreboot, right?) apply microcode update on resume too, or include > newer microcode in OS. > > I want to make one thing clear: I am **not** suggesting this check be > removed altogether. I am suggesting adding an **optional**, even > undocumented, override parameter which defaults to the **current behavior** > which is to panic. > > I've found the patch to be quite stable so far. Unpatched is guaranteed to > cause a crash (xen > panic) at resume; patched so far has not caused any noticeable stability > issues for the four of us > using it, afaik. Just saying. > > Has anyone tried utilizing the xen command line options to mask bits in the cpuid, in particular section 1.2.35 cpuid_mask_ecx)? The man page below says that "Settings applied here take effect globally, including for Xen and all guests." This *might* mean it is applied *before* the resume from sleep CPU bit checks (but I'm not promising anything, as I have not traced through the source). And also "*Warning: This option is not fully effective on Family 15h processors or later.*" https://xenbits.xen.org/docs/4.13-testing/misc/xen-command-line.html Excerpted: ``` 1.2.34 cpuid_mask_cpu = fam_0f_rev_[cdefg] | fam_10_rev_[bc] | fam_11_rev_b Applicability: AMD If none of the other *cpuid_mask_** options are given, Xen has a set of pre-configured masks to make the current processor appear to be family/revision specified. See below for general information on masking. *Warning: This option is not fully effective on Family 15h processors or later.* 1.2.35 cpuid_mask_ecx 1.2.36 cpuid_mask_edx 1.2.37 cpuid_mask_ext_ecx 1.2.38 cpuid_mask_ext_edx 1.2.39 cpuid_mask_l7s0_eax 1.2.40 cpuid_mask_l7s0_ebx 1.2.41 cpuid_mask_thermal_ecx 1.2.42 cpuid_mask_xsave_eax = Applicability: x86. Default: ~0 (all bits set) The availability of these options are model specific. Some processors don't support any of them, and no processor supports all of them. Xen will ignore options on processors which are lacking support. These options can be used to alter the features visible via the CPUID instruction. Settings applied here take effect globally, including for Xen and all guests. Note: Since Xen 4.7, it is no longer necessary to mask a host to create migration safety in heterogeneous scenarios. All necessary CPUID settings should be provided in the VM configuration file. Furthermore, it is recommended not to use this option, as doing so causes an unnecessary reduction of features at Xen's disposal to manage guests. ``` -- 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/808b8f43-2501-4419-a710-f9cd2bb65235%40googlegroups.com.
Re: [qubes-users] Re: R4 system requirements; AMD compatibility?
> marmarek: > This is a very bad idea to "fix" it. Those missing/changed CPUID bits later > on will cause issues. > And given most of the microcode updates recently are about speculative > execution, missing those > features will make the host vulnerable to those issues again. There are > multiple ways it can > manifest - from crashes when Xen uses (now not present) CPU feature, to > silent failures when Xen > tries to use some feature and assume it protects the system, while it does > not in practice. > > For this particular case (microcode included in BIOS newer than in OS), I see > two options: make > BIOS (coreboot, right?) apply microcode update on resume too, or include > newer microcode in OS. I want to make one thing clear: I am **not** suggesting this check be removed altogether. I am suggesting adding an **optional**, even undocumented, override parameter which defaults to the **current behavior** which is to panic. I've found the patch to be quite stable so far. Unpatched is guaranteed to cause a crash (xen panic) at resume; patched so far has not caused any noticeable stability issues for the four of us using it, afaik. Just saying. Also, not everyone has the option of coreboot. And we're not even completely certain this a post-resume microcode update issue, either. > lunarthegray: > @marmarek the "fix" is a hack for sure but it's currently the only way to get > some AMD Ryzen > laptops to work with Qubes. I built Qubes R4.1 the other day and with kernel > 5.4 and Xen 4.13 the > issue remains.Laptop users often suspend and are on the go as I am. There was > some discussion on > the qubes-users mailing list about other solutions. I'm no firmware/Xen > expert though. Would > pinning dom0 to 1 vCPU prevent the issue of missing or changed CPU bits?I'm > not exactly sure what > the fix would be with standard BIOS, as I'm not brave enough to flash > coreboot on my very new > ThinkPad. Should I start trying to get in contact with Lenovo? I'm assuming > AMD needs to release a > microcode patch as it's not really an issue with Xen itself. At least in my case, CPU pinning did not fix this issue. The bits still change and (would) cause a Xen panic as before. Pinning dom0 to CPU0 merely fixed a separate post-resume issue with my SATA controller. In that thread, I link to the original Xen archives thread about pinning which had nothing to do with Ryzen. February 9, 2020 2:09 AM, "Marek Marczykowski-Górecki" wrote: > (continuing discussion from the above PR) > > The patch as it is, is not acceptable, as it may introduce security > and/or stability issues on some machines. Xen (and Linux too) assumes > what CPU features is can use based on CPUID flags. If those changes > during system runtime (including suspend/resume) some instructions or > control registers may no longer be valid (->crash) or safe to use > (->security issue). Like I said, it's been very stable for me so far. I've only had one bad resume in the months I've been using it, suspending at least once a day. Security issues on the other hand are indeed unknown at this point. Also worth noting that this is Xen-specific. Afaik, the Linux kernel doesn't check for these changes. So everyone using plain old Ubuntu or whatever would be subject to the same stability and security implications caused by this patch. > If that's just about microcode updates, that's probably BIOS bug - if it > applies microcode update on system startup, it should do the same on Weird that it's happening equally on various vendor BIOSes as well as coreboot, the only thing they have in common is Ryzen 2xxx-3xxx chips. It doesn't sound to me like a **BIOS** bug, per se, unless all these vendors and the Coreboot developers wrote the same bug independently. More likely an AMD bug, imo. > system resume too. Anyway it's worth trying updating linux-firmware > package, which carries microcode updates for AMD. This should make Xen > apply microcode updates too - before checking those flags. > I've just uploaded updated version of the package to the current-testing > repository (both R4.0 and R4.1). Thanks for the tip. I'll try it when I have a chance. `--enablerepo=qubes-dom0-current-testing kernel-latest linux-firmware` I'm guessing? > If that's about something else, then fixing it would require finding > what exactly is changing (and preferably also why). And only then find > how to mitigate this issue. If specific flags would turn out to be not > related to security features or otherwise having unwanted effects, then > ignoring those changes would be an option. But ignoring _only those > flags verified to be safe to ignore_, not all of them. See my other reply about that. But I would like to mention, there are already all kinds of options and parameters throughout the Xen, Qubes, and Linux codebases that come with stability/security implications. This isn't Apple iOS. You can easily shoot yourself in the foot. That's the nature
Re: [qubes-users] Re: R4 system requirements; AMD compatibility?
On Sun, Feb 9, 2020 at 9:15 AM Claudia 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 Fn0001_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.
Re: [qubes-users] Re: R4 system requirements; AMD compatibility?
February 9, 2020 9:52 AM, zachm1...@gmail.com wrote: > On Sunday, February 9, 2020 at 3:29:26 AM UTC-6, zach...@gmail.com wrote: > >> On Saturday, February 8, 2020 at 8:09:05 PM UTC-6, Marek >> Marczykowski-Górecki wrote: >>> If that's about something else, then fixing it would require finding >>> what exactly is changing (and preferably also why). And only then find >>> how to mitigate this issue. If specific flags would turn out to be not >>> related to security features or otherwise having unwanted effects, then >>> ignoring those changes would be an option. But ignoring _only those >>> flags verified to be safe to ignore_, not all of them. >> >> I hope it doesn't come to that but we'll see. I wouldn't really know what >> else to do besides >> complain to Lenovo and hope they yell up at AMD to investigate. I assume >> it's something weird >> between hardware manufacturers and AMD. >> >>> - -- >>> 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? >>> -BEGIN PGP SIGNATURE- >>> >>> iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAl4/abcACgkQ24/THMrX >>> 1yxEGgf/SG+V7TKM8f7QZ5JFVSr++QasDbMefkuc30OeUkXKtFXsTNMH2fp1S8zq >>> lTgxfrrGH+N7sfP1KkjAZ7ri+DJgmoCyqULUNZAez5DdGlaLJRtsz5rRBtTr4t9F >>> nmJNC859/RPEpbozwxlM6K8JRhlxVg35Sl46E9lYHbNsTBqAywxhTUgENsZlrblh >>> gXn2MgnzDHvwShCltlNL2l29HaAXBzIICpPcgiRWLEY/Y1OTNHvYPiTgZdRtkkEM >>> 5tM97EwxZF31k5i7wGpRed84xCid2bXvufq2Xjo2jWxXuQ01r+bv6v/lVwDvd5tz >>> iOWJsjj4tXLo3bcpuaCM5XvHI9x0yg== >>> =h62J >>> -END PGP SIGNATURE- >> >> P.S. the bits do change for me as stated in the Xen log when I resume from a >> suspend. Here is what >> mine says. >> >> (XEN) CPU0: cap[ 1] is 7ed8320b (expected f6d8320b) > Thanks for sharing that. Just as I expected, bits 31 and 27, xor 0x8800. That makes three of us now. I finally did some digging. I'm wondering if it has to do with the RDRAND issue which has been well known since at least May 7, 2019 to affect Fam15h. This stands to reason, as I immediately updated to the May 19 BIOS update when I bought this machine. awokd had suggested this update, specifically an AGESA update contained within, might have been the cause of an unrelated problem. https://www.phoronix.com/scan.php?page=news_item=AMD-CPUs-RdRand-Suspend https://linuxreviews.org/AMD_finally_submits_kernel_patch_for_broken_RDRAND_on_older_AMD_APUs https://www.mail-archive.com/qubes-users@googlegroups.com/msg31568.html - User awokd's note about AGESA update https://www.mail-archive.com/qubes-users@googlegroups.com/msg31689.html - User Qubes123's investigation into CPUID bits >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 Fn0001_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. -- 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/86dfd10b83e568a734521dfd61f5af90%40disroot.org.
Re: [qubes-users] Re: R4 system requirements; AMD compatibility?
On Sunday, February 9, 2020 at 3:29:26 AM UTC-6, zach...@gmail.com wrote: > > On Saturday, February 8, 2020 at 8:09:05 PM UTC-6, Marek > Marczykowski-Górecki wrote: >> >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA256 >> >> On Fri, Feb 07, 2020 at 02:13:56PM -0800, brend...@gmail.com wrote: >> > On Friday, February 7, 2020 at 9:35:25 PM UTC, zach...@gmail.com >> wrote: >> > > >> > > I preemptively submitted this PR to see what the Qubes team thinks. >> > > https://github.com/QubesOS/qubes-vmm-xen/pull/70 >> > > >> > > I agree it probably should be fixed upstream, although I've seen the >> Qubes >> > > team make exceptions and apply their own changes. Upstream would >> probably >> > > take a huge amount of time to get merged and tested. I'm not a >> developer >> > > though so I'm sure you could explain the issue better than I. If you >> do >> > > mention it, CC me as well! I like the CLI argument idea, that's >> probably a >> > > much cleaner way of doing it and defaulting it to true. That way >> users >> > > could disable it if needed due to hardware screw-ups. >> > > >> > >> > Marek is somewhat active on xen-devel. Submitting the PR to Qubes is >> > probably as good a place to start the (github) discussion I suppose. >> > >> > I expect Claudia is correct that it's really a Xen defect to address, >> > either with a flag to disable the check, or security/stability focused >> > checks only. >> > >> > Xen might point upwards again, of course, and tell AMD to fix their >> > microcode or manufacturer's their BIOS's... >> > >> > ...but if a disable flag could be added (--yes_i_know_what_im_doing >> caveat, >> > of course) that'd be a good short term workaround for the larger Qubes >> user >> > base that is less likely to be able to figure out how to get a build >> > working and rpm applied and keep up to date with upstream. >> >> (continuing discussion from the above PR) >> >> The patch as it is, is not acceptable, as it may introduce security >> and/or stability issues on some machines. Xen (and Linux too) assumes >> what CPU features is can use based on CPUID flags. If those changes >> during system runtime (including suspend/resume) some instructions or >> control registers may no longer be valid (->crash) or safe to use >> (->security issue). >> > > Appreciate you joining the discussion Marek, your input is really valued :) > > >> >> If that's just about microcode updates, that's probably BIOS bug - if it >> applies microcode update on system startup, it should do the same on >> system resume too. Anyway it's worth trying updating linux-firmware >> package, which carries microcode updates for AMD. This should make Xen >> apply microcode updates too - before checking those flags. >> I've just uploaded updated version of the package to the current-testing >> repository (both R4.0 and R4.1). >> > > I totally understand the resistance to merge the PR and that the real > cause of the issue should be fixed in BIOS or OS CPU microcode. > > I will be testing that new linux-firmware package on R4.0 shortly and will > report back, thanks for uploading it. I've used my laptop on and off all > day with suspending it multiple times using the "hacky" patch. If the new > microcode works, it shouldn't write the log line saying it has missing > features. I still have the vmm-xen packages I built with the modified patch > installed. > I installed the new linux-firmware in dom0, rebooted and tested a suspend/resume. Sadly the Xen log says the bits changed still so I'm guessing this will have to be addressed by AMD and hardware manufacturers. Will have to put some thought into what to do next. > > >> >> If that's about something else, then fixing it would require finding >> what exactly is changing (and preferably also why). And only then find >> how to mitigate this issue. If specific flags would turn out to be not >> related to security features or otherwise having unwanted effects, then >> ignoring those changes would be an option. But ignoring _only those >> flags verified to be safe to ignore_, not all of them. >> > > I hope it doesn't come to that but we'll see. I wouldn't really know what > else to do besides complain to Lenovo and hope they yell up at AMD to > investigate. I assume it's something weird between hardware manufacturers > and AMD. > > >> >> - -- >> 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? >> -BEGIN PGP SIGNATURE- >> >> iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAl4/abcACgkQ24/THMrX >> 1yxEGgf/SG+V7TKM8f7QZ5JFVSr++QasDbMefkuc30OeUkXKtFXsTNMH2fp1S8zq >> lTgxfrrGH+N7sfP1KkjAZ7ri+DJgmoCyqULUNZAez5DdGlaLJRtsz5rRBtTr4t9F >> nmJNC859/RPEpbozwxlM6K8JRhlxVg35Sl46E9lYHbNsTBqAywxhTUgENsZlrblh >> gXn2MgnzDHvwShCltlNL2l29HaAXBzIICpPcgiRWLEY/Y1OTNHvYPiTgZdRtkkEM >>
Re: [qubes-users] Re: R4 system requirements; AMD compatibility?
On Saturday, February 8, 2020 at 8:09:05 PM UTC-6, Marek Marczykowski-Górecki wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On Fri, Feb 07, 2020 at 02:13:56PM -0800, brend...@gmail.com > wrote: > > On Friday, February 7, 2020 at 9:35:25 PM UTC, zach...@gmail.com wrote: > > > > > > I preemptively submitted this PR to see what the Qubes team thinks. > > > https://github.com/QubesOS/qubes-vmm-xen/pull/70 > > > > > > I agree it probably should be fixed upstream, although I've seen the > Qubes > > > team make exceptions and apply their own changes. Upstream would > probably > > > take a huge amount of time to get merged and tested. I'm not a > developer > > > though so I'm sure you could explain the issue better than I. If you > do > > > mention it, CC me as well! I like the CLI argument idea, that's > probably a > > > much cleaner way of doing it and defaulting it to true. That way users > > > could disable it if needed due to hardware screw-ups. > > > > > > > Marek is somewhat active on xen-devel. Submitting the PR to Qubes is > > probably as good a place to start the (github) discussion I suppose. > > > > I expect Claudia is correct that it's really a Xen defect to address, > > either with a flag to disable the check, or security/stability focused > > checks only. > > > > Xen might point upwards again, of course, and tell AMD to fix their > > microcode or manufacturer's their BIOS's... > > > > ...but if a disable flag could be added (--yes_i_know_what_im_doing > caveat, > > of course) that'd be a good short term workaround for the larger Qubes > user > > base that is less likely to be able to figure out how to get a build > > working and rpm applied and keep up to date with upstream. > > (continuing discussion from the above PR) > > The patch as it is, is not acceptable, as it may introduce security > and/or stability issues on some machines. Xen (and Linux too) assumes > what CPU features is can use based on CPUID flags. If those changes > during system runtime (including suspend/resume) some instructions or > control registers may no longer be valid (->crash) or safe to use > (->security issue). > Appreciate you joining the discussion Marek, your input is really valued :) > > If that's just about microcode updates, that's probably BIOS bug - if it > applies microcode update on system startup, it should do the same on > system resume too. Anyway it's worth trying updating linux-firmware > package, which carries microcode updates for AMD. This should make Xen > apply microcode updates too - before checking those flags. > I've just uploaded updated version of the package to the current-testing > repository (both R4.0 and R4.1). > I totally understand the resistance to merge the PR and that the real cause of the issue should be fixed in BIOS or OS CPU microcode. I will be testing that new linux-firmware package on R4.0 shortly and will report back, thanks for uploading it. I've used my laptop on and off all day with suspending it multiple times using the "hacky" patch. If the new microcode works, it shouldn't write the log line saying it has missing features. I still have the vmm-xen packages I built with the modified patch installed. > > If that's about something else, then fixing it would require finding > what exactly is changing (and preferably also why). And only then find > how to mitigate this issue. If specific flags would turn out to be not > related to security features or otherwise having unwanted effects, then > ignoring those changes would be an option. But ignoring _only those > flags verified to be safe to ignore_, not all of them. > I hope it doesn't come to that but we'll see. I wouldn't really know what else to do besides complain to Lenovo and hope they yell up at AMD to investigate. I assume it's something weird between hardware manufacturers and AMD. > > - -- > 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? > -BEGIN PGP SIGNATURE- > > iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAl4/abcACgkQ24/THMrX > 1yxEGgf/SG+V7TKM8f7QZ5JFVSr++QasDbMefkuc30OeUkXKtFXsTNMH2fp1S8zq > lTgxfrrGH+N7sfP1KkjAZ7ri+DJgmoCyqULUNZAez5DdGlaLJRtsz5rRBtTr4t9F > nmJNC859/RPEpbozwxlM6K8JRhlxVg35Sl46E9lYHbNsTBqAywxhTUgENsZlrblh > gXn2MgnzDHvwShCltlNL2l29HaAXBzIICpPcgiRWLEY/Y1OTNHvYPiTgZdRtkkEM > 5tM97EwxZF31k5i7wGpRed84xCid2bXvufq2Xjo2jWxXuQ01r+bv6v/lVwDvd5tz > iOWJsjj4tXLo3bcpuaCM5XvHI9x0yg== > =h62J > -END PGP SIGNATURE- > P.S. the bits do change for me as stated in the Xen log when I resume from a suspend. Here is what mine says. (XEN) CPU0: cap[ 1] is 7ed8320b (expected f6d8320b) -- 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
Re: [qubes-users] Re: R4 system requirements; AMD compatibility?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, Feb 07, 2020 at 02:13:56PM -0800, brendan.h...@gmail.com wrote: > On Friday, February 7, 2020 at 9:35:25 PM UTC, zach...@gmail.com wrote: > > > > I preemptively submitted this PR to see what the Qubes team thinks. > > https://github.com/QubesOS/qubes-vmm-xen/pull/70 > > > > I agree it probably should be fixed upstream, although I've seen the Qubes > > team make exceptions and apply their own changes. Upstream would probably > > take a huge amount of time to get merged and tested. I'm not a developer > > though so I'm sure you could explain the issue better than I. If you do > > mention it, CC me as well! I like the CLI argument idea, that's probably a > > much cleaner way of doing it and defaulting it to true. That way users > > could disable it if needed due to hardware screw-ups. > > > > Marek is somewhat active on xen-devel. Submitting the PR to Qubes is > probably as good a place to start the (github) discussion I suppose. > > I expect Claudia is correct that it's really a Xen defect to address, > either with a flag to disable the check, or security/stability focused > checks only. > > Xen might point upwards again, of course, and tell AMD to fix their > microcode or manufacturer's their BIOS's... > > ...but if a disable flag could be added (--yes_i_know_what_im_doing caveat, > of course) that'd be a good short term workaround for the larger Qubes user > base that is less likely to be able to figure out how to get a build > working and rpm applied and keep up to date with upstream. (continuing discussion from the above PR) The patch as it is, is not acceptable, as it may introduce security and/or stability issues on some machines. Xen (and Linux too) assumes what CPU features is can use based on CPUID flags. If those changes during system runtime (including suspend/resume) some instructions or control registers may no longer be valid (->crash) or safe to use (->security issue). If that's just about microcode updates, that's probably BIOS bug - if it applies microcode update on system startup, it should do the same on system resume too. Anyway it's worth trying updating linux-firmware package, which carries microcode updates for AMD. This should make Xen apply microcode updates too - before checking those flags. I've just uploaded updated version of the package to the current-testing repository (both R4.0 and R4.1). If that's about something else, then fixing it would require finding what exactly is changing (and preferably also why). And only then find how to mitigate this issue. If specific flags would turn out to be not related to security features or otherwise having unwanted effects, then ignoring those changes would be an option. But ignoring _only those flags verified to be safe to ignore_, not all of them. - -- 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? -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAl4/abcACgkQ24/THMrX 1yxEGgf/SG+V7TKM8f7QZ5JFVSr++QasDbMefkuc30OeUkXKtFXsTNMH2fp1S8zq lTgxfrrGH+N7sfP1KkjAZ7ri+DJgmoCyqULUNZAez5DdGlaLJRtsz5rRBtTr4t9F nmJNC859/RPEpbozwxlM6K8JRhlxVg35Sl46E9lYHbNsTBqAywxhTUgENsZlrblh gXn2MgnzDHvwShCltlNL2l29HaAXBzIICpPcgiRWLEY/Y1OTNHvYPiTgZdRtkkEM 5tM97EwxZF31k5i7wGpRed84xCid2bXvufq2Xjo2jWxXuQ01r+bv6v/lVwDvd5tz iOWJsjj4tXLo3bcpuaCM5XvHI9x0yg== =h62J -END PGP SIGNATURE- -- 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/20200209020855.GC29736%40mail-itl.
Re: [qubes-users] Re: R4 system requirements; AMD compatibility?
On Friday, February 7, 2020 at 9:35:25 PM UTC, zach...@gmail.com wrote: > > I preemptively submitted this PR to see what the Qubes team thinks. > https://github.com/QubesOS/qubes-vmm-xen/pull/70 > > I agree it probably should be fixed upstream, although I've seen the Qubes > team make exceptions and apply their own changes. Upstream would probably > take a huge amount of time to get merged and tested. I'm not a developer > though so I'm sure you could explain the issue better than I. If you do > mention it, CC me as well! I like the CLI argument idea, that's probably a > much cleaner way of doing it and defaulting it to true. That way users > could disable it if needed due to hardware screw-ups. > Marek is somewhat active on xen-devel. Submitting the PR to Qubes is probably as good a place to start the (github) discussion I suppose. I expect Claudia is correct that it's really a Xen defect to address, either with a flag to disable the check, or security/stability focused checks only. Xen might point upwards again, of course, and tell AMD to fix their microcode or manufacturer's their BIOS's... ...but if a disable flag could be added (--yes_i_know_what_im_doing caveat, of course) that'd be a good short term workaround for the larger Qubes user base that is less likely to be able to figure out how to get a build working and rpm applied and keep up to date with upstream. Brendan -- 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/0ee7aa01-5daf-4d71-bc06-2d061994f7ca%40googlegroups.com.
Re: [qubes-users] Re: R4 system requirements; AMD compatibility?
On Friday, February 7, 2020 at 3:15:38 PM UTC-6, Claudia wrote: > > February 7, 2020 8:10 PM, zach...@gmail.com wrote: > > > On Friday, February 7, 2020 at 2:07:34 PM UTC-6, zach...@gmail.com > wrote: > > > >> On Friday, February 7, 2020 at 7:03:14 AM UTC-6, Claudia wrote: > >>> February 7, 2020 6:00 AM, zach...@gmail.com wrote:> I have a Thinkpad > T495 with an AMD Ryzen Pro > >>> 3700U and Vega 10 graphics. Everything seems to be > working besides suspend/resume which is crucial for me since I'm on > the go a lot. I had to build > >>> my > own Qubes R4.0 ISO to get the installer to work due to it needing a > 5.0+ kernel for the graphics > driver. I installed `kernel-latest` from qubes-dom0-current testing > but still didn't work. After > trying every kernel option on the face of this Earth I decided to use > an experimental Qubes R4.1 > build as some things were pointing to dom0 Fedora 25 being the issue. > On dom0 Fedora 31 it's > >>> still > an issue with a 5.4 kernel. Has been driving me nuts as I've spent > almost the whole day trying to > figure the issue out. > > When I suspend, it clearly suspends but when I open it back up the > screen is off but the power > >>> LED > is on. I can hear the fan spin up for a bit but nothing happens. CTRL > + ALT + Backspace does > nothing. I also tried switching to text mode before suspending with > CTRL + ALT + F2. Nothing... I > also disabled the compositor in XFCE to give it a try in both R4.0 > and R4.1, no difference. It > totally seems like an X server or amdgpu issue but I really don't > know what to do. > > I don't have any VMs running when I test the suspend and I don't have > a sys-usb VM to take that > >>> out > of the equation. Any ideas? I'm scratching my head over here and I'm > at a loss on what to try > >>> next. > > >>> > >>> Did you try the Xen power.c patch? > >>> > >>> It sounds like a Xen panic. Some or all AMD Fam15h processors change > their CPUID feature bits after > >>> resume, which triggers a Xen panic (LEDs and fans on, screen off, > keyboard and power button > >>> unresponsive). There is a patch and instructions towards the end of > this thread: > >>> > https://www.mail-archive.com/qubes-users@googlegroups.com/msg31517.html - > It takes some work but it > >>> sounds very likely it will fix your problem. Sys-usb causes other > problems on a lot of Ryzen > >>> machines, so continue to keep it disabled for now. > >>> > >>> It doesn't sound like a graphics problem. Usually X or amdgpu issues > result in the screen's > >>> backlight coming on but displaying a blank screen, and often the > keyboard is responsive just not > >>> the screen. At least in my experience. > >>> > >>> PS: when replying to mailing lists please write your response *below* > the quoted text you're > >>> replying to. > >> > >> Thanks for responding Claudia! I haven't tried that patch but I saw it > in your other thread. I > >> guess my options are pretty exhausted at this point so I'll give it a > try. I've never actually > >> built an RPM outside of qubes-builder. I'm assuming I should just build > the entire Qubes R4.0 > >> (stable) ISO with the edit included. I've never had such a complex > issue before so this is all new > >> to me. > > Not sure what you mean about building an RPM outside qubes-builder. This > is all done within qubes-builder. So if you have any experience at all with > that, then you're already off to a way better start than I was. It wasn't > nearly as bad as I thought it would be either. The GUI script does most of > the work for you. I tried to leave a sufficiently detailed diary of what I > did because I knew it would come in handy later (whether for myself or > others). And, you can always ask the mailing list for help. > > I just built the RPMs. Building the whole ISO apparently takes many hours > and many GB of disk space. And, as with building anything, keep in mind if > something goes wrong mid-build, there's a good chance you'll have to start > over from the beginning. It took me several attempts. Either method should > work the same though, so it's up to you. > Took me a bit to figure out but I applied the changes to `patch-x86-check-feature-flags-after-resume.patch` and I'm building the whole ISO now. I'm not actually sure how to build the RPM itself, and not the ISO. To be honest I've got like 100 tabs open so maybe I'm missing something... Once the ISO builds and I install it, I assume I just want to add vmm-xen to my yum/dnf excludes so no new vmm-xen package gets installed without the patch. > >> Should we get the Qubes team to include this patch as a fix for AMD? > I'm not sure what the security > >> implications are but I would assume it could introduce an issue where > the Spectre/Meltdown > >> microcode patches would not be applied when resuming? I'm also assuming > the code is
Re: [qubes-users] Re: R4 system requirements; AMD compatibility?
February 7, 2020 8:10 PM, zachm1...@gmail.com wrote: > On Friday, February 7, 2020 at 2:07:34 PM UTC-6, zach...@gmail.com wrote: > >> On Friday, February 7, 2020 at 7:03:14 AM UTC-6, Claudia wrote: >>> February 7, 2020 6:00 AM, zach...@gmail.com wrote:> I have a Thinkpad T495 >>> with an AMD Ryzen Pro >>> 3700U and Vega 10 graphics. Everything seems to be working besides suspend/resume which is crucial for me since I'm on the go a lot. I had to build >>> my own Qubes R4.0 ISO to get the installer to work due to it needing a 5.0+ kernel for the graphics driver. I installed `kernel-latest` from qubes-dom0-current testing but still didn't work. After trying every kernel option on the face of this Earth I decided to use an experimental Qubes R4.1 build as some things were pointing to dom0 Fedora 25 being the issue. On dom0 Fedora 31 it's >>> still an issue with a 5.4 kernel. Has been driving me nuts as I've spent almost the whole day trying to figure the issue out. When I suspend, it clearly suspends but when I open it back up the screen is off but the power >>> LED is on. I can hear the fan spin up for a bit but nothing happens. CTRL + ALT + Backspace does nothing. I also tried switching to text mode before suspending with CTRL + ALT + F2. Nothing... I also disabled the compositor in XFCE to give it a try in both R4.0 and R4.1, no difference. It totally seems like an X server or amdgpu issue but I really don't know what to do. I don't have any VMs running when I test the suspend and I don't have a sys-usb VM to take that >>> out of the equation. Any ideas? I'm scratching my head over here and I'm at a loss on what to try >>> next. >>> >>> Did you try the Xen power.c patch? >>> >>> It sounds like a Xen panic. Some or all AMD Fam15h processors change their >>> CPUID feature bits after >>> resume, which triggers a Xen panic (LEDs and fans on, screen off, keyboard >>> and power button >>> unresponsive). There is a patch and instructions towards the end of this >>> thread: >>> https://www.mail-archive.com/qubes-users@googlegroups.com/msg31517.html - >>> It takes some work but it >>> sounds very likely it will fix your problem. Sys-usb causes other problems >>> on a lot of Ryzen >>> machines, so continue to keep it disabled for now. >>> >>> It doesn't sound like a graphics problem. Usually X or amdgpu issues result >>> in the screen's >>> backlight coming on but displaying a blank screen, and often the keyboard >>> is responsive just not >>> the screen. At least in my experience. >>> >>> PS: when replying to mailing lists please write your response *below* the >>> quoted text you're >>> replying to. >> >> Thanks for responding Claudia! I haven't tried that patch but I saw it in >> your other thread. I >> guess my options are pretty exhausted at this point so I'll give it a try. >> I've never actually >> built an RPM outside of qubes-builder. I'm assuming I should just build the >> entire Qubes R4.0 >> (stable) ISO with the edit included. I've never had such a complex issue >> before so this is all new >> to me. Not sure what you mean about building an RPM outside qubes-builder. This is all done within qubes-builder. So if you have any experience at all with that, then you're already off to a way better start than I was. It wasn't nearly as bad as I thought it would be either. The GUI script does most of the work for you. I tried to leave a sufficiently detailed diary of what I did because I knew it would come in handy later (whether for myself or others). And, you can always ask the mailing list for help. I just built the RPMs. Building the whole ISO apparently takes many hours and many GB of disk space. And, as with building anything, keep in mind if something goes wrong mid-build, there's a good chance you'll have to start over from the beginning. It took me several attempts. Either method should work the same though, so it's up to you. >> Should we get the Qubes team to include this patch as a fix for AMD? I'm not >> sure what the security >> implications are but I would assume it could introduce an issue where the >> Spectre/Meltdown >> microcode patches would not be applied when resuming? I'm also assuming the >> code is functioning as >> intended, as it panics but what would the real solution be? I wonder if >> there's any official fix by >> Xen in the works rather than commenting out that panic line. Even in Qubes >> R4.1 with Xen 4.13 the >> issue persists. I've been thinking about that. I asked the original author if he reported it to upstream or intended to, but I never heard back from him. I think the Qubes devs would probably just say it's Xen's responsibility, and I can't say I disagree. I've been meaning to mention it on xen-devel but haven't gotten around to it. You're welcome to do so too if
Re: [qubes-users] Re: R4 system requirements; AMD compatibility?
On Friday, February 7, 2020 at 2:07:34 PM UTC-6, zach...@gmail.com wrote: > > On Friday, February 7, 2020 at 7:03:14 AM UTC-6, Claudia wrote: >> >> February 7, 2020 6:00 AM, zach...@gmail.com wrote: >> >> > I have a Thinkpad T495 with an AMD Ryzen Pro 3700U and Vega 10 >> graphics. Everything seems to be >> > working besides suspend/resume which is crucial for me since I'm on the >> go a lot. I had to build my >> > own Qubes R4.0 ISO to get the installer to work due to it needing a >> 5.0+ kernel for the graphics >> > driver. I installed `kernel-latest` from qubes-dom0-current testing but >> still didn't work. After >> > trying every kernel option on the face of this Earth I decided to use >> an experimental Qubes R4.1 >> > build as some things were pointing to dom0 Fedora 25 being the issue. >> On dom0 Fedora 31 it's still >> > an issue with a 5.4 kernel. Has been driving me nuts as I've spent >> almost the whole day trying to >> > figure the issue out. >> > >> > When I suspend, it clearly suspends but when I open it back up the >> screen is off but the power LED >> > is on. I can hear the fan spin up for a bit but nothing happens. CTRL + >> ALT + Backspace does >> > nothing. I also tried switching to text mode before suspending with >> CTRL + ALT + F2. Nothing... I >> > also disabled the compositor in XFCE to give it a try in both R4.0 and >> R4.1, no difference. It >> > totally seems like an X server or amdgpu issue but I really don't know >> what to do. >> > >> > I don't have any VMs running when I test the suspend and I don't have a >> sys-usb VM to take that out >> > of the equation. Any ideas? I'm scratching my head over here and I'm at >> a loss on what to try next. >> > >> >> Did you try the Xen power.c patch? >> >> It sounds like a Xen panic. Some or all AMD Fam15h processors change >> their CPUID feature bits after resume, which triggers a Xen panic (LEDs and >> fans on, screen off, keyboard and power button unresponsive). There is a >> patch and instructions towards the end of this thread: >> https://www.mail-archive.com/qubes-users@googlegroups.com/msg31517.html >> - It takes some work but it sounds very likely it will fix your problem. >> Sys-usb causes other problems on a lot of Ryzen machines, so continue to >> keep it disabled for now. >> >> It doesn't sound like a graphics problem. Usually X or amdgpu issues >> result in the screen's backlight coming on but displaying a blank screen, >> and often the keyboard is responsive just not the screen. At least in my >> experience. >> >> PS: when replying to mailing lists please write your response *below* the >> quoted text you're replying to. >> > > Thanks for responding Claudia! I haven't tried that patch but I saw it in > your other thread. I guess my options are pretty exhausted at this point so > I'll give it a try. I've never actually built an RPM outside of > qubes-builder. I'm assuming I should just build the entire Qubes R4.0 > (stable) ISO with the edit included. I've never had such a complex issue > before so this is all new to me. > > Should we get the Qubes team to include this patch as a fix for AMD? I'm > not sure what the security implications are but I would assume it could > introduce an issue where the Spectre/Meltdown microcode patches would not > be applied when resuming? I'm also assuming the code is functioning as > intended, as it panics but what would the real solution be? I wonder if > there's any official fix by Xen in the works rather than commenting out > that panic line. Even in Qubes R4.1 with Xen 4.13 the issue persists. > > Sorry about the email above yours, Google groups wants to put it above > your quote by default for some reason. I was also exhausted from trying > 1000 kernel boot options lol. > Also... The patch shouldn't really have any security implications assuming your BIOS has the latest microcode patches right? I'm guessing this is only for microcode packages installed on the OS. -- 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/b6408d0f-228f-4ce1-8ccb-600a79d3421c%40googlegroups.com.
Re: [qubes-users] Re: R4 system requirements; AMD compatibility?
On Friday, February 7, 2020 at 7:03:14 AM UTC-6, Claudia wrote: > > February 7, 2020 6:00 AM, zach...@gmail.com wrote: > > > I have a Thinkpad T495 with an AMD Ryzen Pro 3700U and Vega 10 graphics. > Everything seems to be > > working besides suspend/resume which is crucial for me since I'm on the > go a lot. I had to build my > > own Qubes R4.0 ISO to get the installer to work due to it needing a 5.0+ > kernel for the graphics > > driver. I installed `kernel-latest` from qubes-dom0-current testing but > still didn't work. After > > trying every kernel option on the face of this Earth I decided to use an > experimental Qubes R4.1 > > build as some things were pointing to dom0 Fedora 25 being the issue. On > dom0 Fedora 31 it's still > > an issue with a 5.4 kernel. Has been driving me nuts as I've spent > almost the whole day trying to > > figure the issue out. > > > > When I suspend, it clearly suspends but when I open it back up the > screen is off but the power LED > > is on. I can hear the fan spin up for a bit but nothing happens. CTRL + > ALT + Backspace does > > nothing. I also tried switching to text mode before suspending with CTRL > + ALT + F2. Nothing... I > > also disabled the compositor in XFCE to give it a try in both R4.0 and > R4.1, no difference. It > > totally seems like an X server or amdgpu issue but I really don't know > what to do. > > > > I don't have any VMs running when I test the suspend and I don't have a > sys-usb VM to take that out > > of the equation. Any ideas? I'm scratching my head over here and I'm at > a loss on what to try next. > > > > Did you try the Xen power.c patch? > > It sounds like a Xen panic. Some or all AMD Fam15h processors change their > CPUID feature bits after resume, which triggers a Xen panic (LEDs and fans > on, screen off, keyboard and power button unresponsive). There is a patch > and instructions towards the end of this thread: > https://www.mail-archive.com/qubes-users@googlegroups.com/msg31517.html - > It takes some work but it sounds very likely it will fix your problem. > Sys-usb causes other problems on a lot of Ryzen machines, so continue to > keep it disabled for now. > > It doesn't sound like a graphics problem. Usually X or amdgpu issues > result in the screen's backlight coming on but displaying a blank screen, > and often the keyboard is responsive just not the screen. At least in my > experience. > > PS: when replying to mailing lists please write your response *below* the > quoted text you're replying to. > Thanks for responding Claudia! I haven't tried that patch but I saw it in your other thread. I guess my options are pretty exhausted at this point so I'll give it a try. I've never actually built an RPM outside of qubes-builder. I'm assuming I should just build the entire Qubes R4.0 (stable) ISO with the edit included. I've never had such a complex issue before so this is all new to me. Should we get the Qubes team to include this patch as a fix for AMD? I'm not sure what the security implications are but I would assume it could introduce an issue where the Spectre/Meltdown microcode patches would not be applied when resuming? I'm also assuming the code is functioning as intended, as it panics but what would the real solution be? I wonder if there's any official fix by Xen in the works rather than commenting out that panic line. Even in Qubes R4.1 with Xen 4.13 the issue persists. Sorry about the email above yours, Google groups wants to put it above your quote by default for some reason. I was also exhausted from trying 1000 kernel boot options lol. -- 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/c773d991-264b-4c36-bae9-51201a670cc9%40googlegroups.com.
Re: [qubes-users] Re: R4 system requirements; AMD compatibility?
February 7, 2020 1:03 PM, "Claudia" wrote: > February 7, 2020 6:00 AM, zachm1...@gmail.com wrote: > >> I have a Thinkpad T495 with an AMD Ryzen Pro 3700U and Vega 10 graphics. >> Everything seems to be >> working besides suspend/resume which is crucial for me since I'm on the go a >> lot. I had to build my >> own Qubes R4.0 ISO to get the installer to work due to it needing a 5.0+ >> kernel for the graphics >> driver. I installed `kernel-latest` from qubes-dom0-current testing but >> still didn't work. After >> trying every kernel option on the face of this Earth I decided to use an >> experimental Qubes R4.1 >> build as some things were pointing to dom0 Fedora 25 being the issue. On >> dom0 Fedora 31 it's still >> an issue with a 5.4 kernel. Has been driving me nuts as I've spent almost >> the whole day trying to >> figure the issue out. >> >> When I suspend, it clearly suspends but when I open it back up the screen is >> off but the power LED >> is on. I can hear the fan spin up for a bit but nothing happens. CTRL + ALT >> + Backspace does >> nothing. I also tried switching to text mode before suspending with CTRL + >> ALT + F2. Nothing... I >> also disabled the compositor in XFCE to give it a try in both R4.0 and R4.1, >> no difference. It >> totally seems like an X server or amdgpu issue but I really don't know what >> to do. >> >> I don't have any VMs running when I test the suspend and I don't have a >> sys-usb VM to take that out >> of the equation. Any ideas? I'm scratching my head over here and I'm at a >> loss on what to try next. > > Did you try the Xen power.c patch? > > It sounds like a Xen panic. Some or all AMD Fam15h processors change their > CPUID feature bits after > resume, which triggers a Xen panic (LEDs and fans on, screen off, keyboard > and power button > unresponsive). There is a patch and instructions towards the end of this > thread: > https://www.mail-archive.com/qubes-users@googlegroups.com/msg31517.html - It > takes some work but it > sounds very likely it will fix your problem. Sys-usb causes other problems on > a lot of Ryzen > machines, so continue to keep it disabled for now. > > It doesn't sound like a graphics problem. Usually X or amdgpu issues result > in the screen's > backlight coming on but displaying a blank screen, and often the keyboard is > responsive just not > the screen. At least in my experience. > > PS: when replying to mailing lists please write your response *below* the > quoted text you're > replying to. Also I forgot to mention, if the patch works but you still run into other post-resume problems, you may have to pin dom0 to CPU0. See https://www.mail-archive.com/qubes-users@googlegroups.com/msg31737.html -- 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/98262c7f7b6c7ec43a72657febed1545%40disroot.org.
Re: [qubes-users] Re: R4 system requirements; AMD compatibility?
February 7, 2020 6:00 AM, zachm1...@gmail.com wrote: > I have a Thinkpad T495 with an AMD Ryzen Pro 3700U and Vega 10 graphics. > Everything seems to be > working besides suspend/resume which is crucial for me since I'm on the go a > lot. I had to build my > own Qubes R4.0 ISO to get the installer to work due to it needing a 5.0+ > kernel for the graphics > driver. I installed `kernel-latest` from qubes-dom0-current testing but still > didn't work. After > trying every kernel option on the face of this Earth I decided to use an > experimental Qubes R4.1 > build as some things were pointing to dom0 Fedora 25 being the issue. On dom0 > Fedora 31 it's still > an issue with a 5.4 kernel. Has been driving me nuts as I've spent almost the > whole day trying to > figure the issue out. > > When I suspend, it clearly suspends but when I open it back up the screen is > off but the power LED > is on. I can hear the fan spin up for a bit but nothing happens. CTRL + ALT + > Backspace does > nothing. I also tried switching to text mode before suspending with CTRL + > ALT + F2. Nothing... I > also disabled the compositor in XFCE to give it a try in both R4.0 and R4.1, > no difference. It > totally seems like an X server or amdgpu issue but I really don't know what > to do. > > I don't have any VMs running when I test the suspend and I don't have a > sys-usb VM to take that out > of the equation. Any ideas? I'm scratching my head over here and I'm at a > loss on what to try next. > Did you try the Xen power.c patch? It sounds like a Xen panic. Some or all AMD Fam15h processors change their CPUID feature bits after resume, which triggers a Xen panic (LEDs and fans on, screen off, keyboard and power button unresponsive). There is a patch and instructions towards the end of this thread: https://www.mail-archive.com/qubes-users@googlegroups.com/msg31517.html - It takes some work but it sounds very likely it will fix your problem. Sys-usb causes other problems on a lot of Ryzen machines, so continue to keep it disabled for now. It doesn't sound like a graphics problem. Usually X or amdgpu issues result in the screen's backlight coming on but displaying a blank screen, and often the keyboard is responsive just not the screen. At least in my experience. PS: when replying to mailing lists please write your response *below* the quoted text you're replying to. -- 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/929c8ac5e136abf7258a1c91d6f58fae%40disroot.org.
[qubes-users] Re: R4 system requirements; AMD compatibility?
I have a Thinkpad T495 with an AMD Ryzen Pro 3700U and Vega 10 graphics. Everything seems to be working besides suspend/resume which is crucial for me since I'm on the go a lot. I had to build my own Qubes R4.0 ISO to get the installer to work due to it needing a 5.0+ kernel for the graphics driver. I installed `kernel-latest` from qubes-dom0-current testing but still didn't work. After trying every kernel option on the face of this Earth I decided to use an experimental Qubes R4.1 build as some things were pointing to dom0 Fedora 25 being the issue. On dom0 Fedora 31 it's still an issue with a 5.4 kernel. Has been driving me nuts as I've spent almost the whole day trying to figure the issue out. When I suspend, it clearly suspends but when I open it back up the screen is off but the power LED is on. I can hear the fan spin up for a bit but nothing happens. CTRL + ALT + Backspace does nothing. I also tried switching to text mode before suspending with CTRL + ALT + F2. Nothing... I also disabled the compositor in XFCE to give it a try in both R4.0 and R4.1, no difference. It totally seems like an X server or amdgpu issue but I really don't know what to do. I don't have any VMs running when I test the suspend and I don't have a sys-usb VM to take that out of the equation. Any ideas? I'm scratching my head over here and I'm at a loss on what to try next. On Wednesday, May 22, 2019 at 8:46:12 AM UTC-5, Claudia wrote: > > Hello, > > I've read the system requirements page, the HCL, and the "advice on > finding a Qubes compatible notebook" thread, all of which seem to refer > to Intel almost exclusively. I've also done some searching around, but > there seems to be very little information about Qubes' compatibility on > AMD machines. > > I already know the conventional wisdom is "buy it, try it, and return it > if it doesn't work," and that's basically what I intend to do. But > before I do, I'm hoping for some reassurance, or advice on whether I > should just skip over AMD altogether. > > Is Qubes support for AMD about as good as it is for Intel? Or, is there > a reason to pay the extra money for an Intel machine? Why is there so > little information about Qubes on AMD, and so few AMD machines on the > HCL? Surely I can't be the only person wondering about this. > > A few things, more specifically: > > 1) The system requirements page says that Intel integrated graphics are > strongly recommended over Nvidia or Radeon, for compatibility reasons. > What about AMD's integrated "Vega" graphics? > > 2) It's harder to find compatibility-related information for AMD > processors. In particular, information about whether RVI ( = Intel EPT, > = SLAT) is supported by a given processor. Official specs, and even > sites like wikichip.org and cpu-monkey.com, often mention Intel EPT but > not AMD RVI. (AMD-V and IOMMU are usually mentioned, though). Is there a > specific cpu flag or something that I should be looking for in order to > know if RVI is supported? Or is it pretty much safe to assume that any > recent AMD processor with AMD-V and IOMMU will also support RVI? > > 3) Do AMD processors have integrated chipsets like Intel (4th gen and > up) processors? Or does the chipset remain on the motherboard in AMD > machines. Not a dealbreaker, but integrated chipsets definitely make > searching much easier. > > For what it's worth, in particular I'm looking at a few laptops with > processors such as Ryzen 5 2500U, Ryzen 7 2700U, and Ryzen 5 3500U. They > seem like great deal for the money. For example the 2500U has about the > same specs/performance as an i5-8250U, but laptops with the 2500U tend > to be around $200 cheaper than the Intel version. But, if Qubes > compatibility is most likely going to be an issue, then I'm willing to > pay the extra money for an Intel machine and avoid the hassle. > > So, can I expect to have about the same luck with AMD as Intel? Or > should I just pay the extra money and play it safe with Intel? Any > advice on these particular processors, or recent AMD processors in > general, it would make me feel a lot better before I go buying and > trying at random. > > - > > ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of > the NSA's hands! > $24.95 ONETIME Lifetime accounts with Privacy Features! > 15GB disk! No bandwidth quotas! > Commercial and Bulk Mail Options! > -- 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/d11956ef-5939-41e7-a0e4-009add7b228a%40googlegroups.com.
[qubes-users] Re: R4 system requirements; AMD compatibility?
I haven't personally tried this but I am highly confident that Qubes will definitely work on an ASRock X370 Taichi https://www.asrock.com/mb/AMD/X370%20Taichi/ It's the motherboard out there that has aced being able to do GPU Passthrough on a Windows Guest VM on a Linux Host so all in all it's very reliable for Qubes' many VM requirements and has done very well to reliably run various linux distros just by me reading through alot of pages/articles about doing GPU passthrough in linux All in all, it's really worth the try and even if it doesn't work on qubes then maybe it will work on considerable alternatives like Subgraph OS. https://subgraph.com/ There's X470 and X570 out already but I'm not sure how it fares with Qubes OS given that there's alot of new stuff going on in there right now that may not be compatible or working well with Linux. -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/5a4c9c93-d801-4bde-aac6-25fc3cb2aad0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
