Back

@ariadne this is basically the opposite of PC evolution which went from a fully open system (which I grew up on) to trying to figure out how to secure it (TPM, TXT, DRTM etc.). The QC SoCs started with the mobile ecosystem with a strict boot chain locked to the device manufacturer, and it is loosening up. The Gunyah hypervisor early boot is mainly there to make sure the peripherals and their firmware are properly initialized and isolated. It is then switched to the platform hypervisor on Windows systems (and to Linux on EL2 with the slbounce thing). And yes, this is a much longer way of saying that it is not really possible to make it go away in a correctly configured device. @never_released

@canacar @never_released then can we at least get a fix for it to make it work with 64GB of RAM?

@ariadne @never_released this is in my list to follow up on but things were quite busy recently. I suspect the DT available at boot is a generic one where "32G should be enough for everyone". If so Lenovo may have to provide an update. Are there any other publicly available bug reports or discussions on this I can refer to when discussing internally?

@canacar @ariadne this isn't about the DT itself but that Gunyah doesn't map the full 64G

Doesn't matter for Windows because Snapdragon X has Secure Launch forced to always-on even for WinPE but breaks booting any OS that doesn't escalate to EL2 without cutting down available memory

@never_released @ariadne is this just the memory Gunyah reserves for itself and other use cases (that may not be applicable to Linux?) I thought the missing memory was on the order of Gigabytes, so I assumed a configuration issue somewhere. I will bring this up with the right teams, but having a good description will help a lot.

@canacar @ariadne the UEFI memory map that is given to the OS is invalid and contains memory that will be faulted on access

@never_released @ariadne but how would that lead to missing memory?

@canacar @ariadne to be able to boot the OS at all you have to override memory to cut the upper half, otherwise it'll crash really early when trying to access it

@never_released @ariadne do you know how Android handles this? I will probably find out next week but still ...

@canacar @ariadne no Android QCOM devices with >32GB of RAM, and that was the limit until the SoC memory map got reworked for Snapdragon X, which is pretty recent

@canacar @never_released thanks :)

@ariadne @never_released apparently there is a Gunyah fix that Lenovo (and others) can take that addresses the 32G problem. I did hear there may be other issues, though. I will keep asking. It seems complaining to Lenovo may help.

I also learned that slbounce is probably not a very good alternative because most on chip peripherals (audio etc) would not work. Even though upstream Linux drivers exist, they also need peripheral loading support from Gunyah (for proper initialization/reset etc.)

@canacar @ariadne PIL bring up without QHEE or Gunyah is already there upstream for some platforms because of chromeOS, but unfortunately not 8280/8380. It'd take some upstream work to close the gap.

@never_released @ariadne the ChromeOS solution is not really scalable as you point out. We have a better alternative under development but don't hold your breath...