qubes-issues
qubes-issues copied to clipboard
QubesOS
Support for the S0ix sleep state
Current status
Initial support of S0ix is available for testing; see https://github.com/QubesOS/qubes-issues/issues/6411#issuecomment-2089227397.
Editor's note: The original issue description below is somewhat out-of-date. This issue is now narrowly focused on support for the S0ix sleep state (aka "Modern Standby," "Low Power S0 Idle," "InstantGo," "Connected Standby," etc.) found in newer CPUs (especially Tiger Lake and later).
The problem you're addressing (if any)
It appears Qubes does not support Intel's latest version of processors.
Describe the solution you'd like
Support for Intel's latest version of their processors (i.e., tiger lake)
Where is the value to a user, and who might that user be?
People who want to benefit from the significant performance upgrades of Tiger Lake
Describe alternatives you've considered
N/A
Additional context
N/A
Relevant documentation you've consulted
N/A (I've checked GitHub for any open issues on this but either I've missed it or my SearchFu is weak)
Related, non-duplicate issues
N/A
@marmarek I believe this has to do with the current kernel Qubes is using?
That would not surprise me. R4.1 has several advantages here, including being able to include multiple kernels in the install ISO.
@DemiMarie, does that mean R4.1 will support Tiger Lake? Sorry if I'm being obtuse.
@e6lk7dqzm83p that’s a question that @marmarek would be better positioned to answer, sorry.
I believe this is close related to https://github.com/QubesOS/qubes-issues/issues/5374, which this time is more about Xen than Linux. @e6lk7dqzm83p do you see some specific error message?
Apologies, I do not. I was talking to System76 about about their Qubes support with the newer chipsets and was informed that Tiger Lake was not currently supported due to a kernel issue (I'm trying to ensure Qubes support before I purchase my new computer). I was trying to see what the status of that issue was and couldn't find any documentation here so I opened the request.
Sorry if that was in error/off protocol.
Generally, for Intel systems >=10th gen I'd recommend trying Qubes 4.1. Some may work with Qubes 4.0.x too, but backporting some of the hardware support parts (especially on Xen part) is impractical.
Any chance of seeing a new testing release of 4.1 built soon? The last one I know of in the repo is 6+ months old, especially with the HPET fix just landed, it'd be great to have an updated installer.
Managed to find https://openqa.qubes-os.org/group_overview/1
Not documented anywhere that I can find, but it does appear to be the output of the automated build system from time to time. Last build for 4.1 was ~7 days ago, won't contain these fixes, and failed. What is the current channel for getting the latest 4.1 iso, if any other than this or the kernel.org mirrors?
openQA is the right place for looking for test builds. But note the CI system is not a trusted build environment, so do not use those builds for anything else than testing.
@marmarek when I tested TGL system76 hardware with qubes 4.0 I was able to boot it via modification of the coreboot firmware. Checkout this patch: https://github.com/system76/coreboot/pull/42 What I was not able to fix were suspend issues, as Intel has dropped S3 support with TGL and moved to s0ix only. Does Qubes 4.1 with Xen 4.14 support s0ix suspend?
Does Qubes 4.1 with Xen 4.14 support s0ix suspend?
Sadly, not.
I wonder if we should reconsider staying on a single Xen version for an entire release. This leads to rather awkward hardware support problems.
Does Xen 4.15 support s0ix?
No, and I'm just learning how absurdly unfriendly to virtualization power management on newest Intel platform is.
@marmarek, an update: I have a System76 Tiger Lake machine and tried the 4.1 Alpha ISO from October with no luck. I don't get the panic error, and Grub does load, but after you try to do a live boot or install it just resets.
I have a System76 Tiger Lake machine and tried the 4.1
I have too, for this specific development :)
Alpha ISO from October with no luck
Recent @fepitre's build works, although suspend is broken (unsurprisingly).
On Sat, Apr 10, 2021 at 04:23:06AM -0700, Marek Marczykowski-Górecki wrote:
I have a System76 Tiger Lake machine and tried the 4.1 I do too, for this specific development :)
nice :)
Alpha ISO from October with no luck Recent @fepitre's build works, although suspend is broken (unsurprisingly).
if that's a tracked issue, where is it tracked? :) or is it known and eg fixed in the next kernel? or?
-- cheers, Holger
⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C ⠈⠳⣄
If nothing saves us from death, may love at least save us from life.
if that's a tracked issue, where is it tracked?
Here, see few comments above about S3 and S0ix. That's the major part of Tiger Lake processors support.
thanks. so it's a xen issue unfixed upstream..
Power management on Tiger Lake requires cooperation from virtually all drivers, which is extremely unfriendly to PCI pass-through. Attempts to suspend the system without the cooperation of the driver domains could place various hardware components in an undefined state. The only workaround currently available is to avoid suspending the system.
What would be the best way to try @fepitre's build? This is my first time using the Qubes builder, and I keep getting errors when I attempt to use his repo. I would also like to avoid building more from source than necessary; which components can safely be filtered out?
@marmarek I'd like to add my voice to the request for a version of @fepitre's build (preferably that's been signed by the Qubes Master Key).
I personally don't mind suspend not working as it hasn't worked for most of the time I've been running Qubes, so I don't view it as necessary functionality.
Take a look at https://qubes-os.discourse.group/t/qubesos-weekly-builds/3601
@marmarek I'd like to add my voice to the request for a version of @fepitre's build (preferably that's been signed by the Qubes Master Key).
Nit: I believe the Qubes Master Signing Key (QMSK) is only used to sign other keys. I assume you meant “has a chain of trust to the QMSK”, which I support.
That won't happen, at least not directly. I will not sign a build done somewhere else, with a trusted key. This also means, @fepitre-bot's key won't be signed with QMSK. But we can include its fingerprint somewhere on the website for example (https://www.qubes-os.org/doc/testing/ ?)
I was more proposing having the Qubes team build and sign an updated Alpha that would at least boot on Tiger Lake; the last signed ISO I can find is from October 2020.
Sorry for the confusion!