When SGX is not supported by the BIOS, the kernel log still output
the error 'SGX disabled by BIOS', which can be confusing since
there might not be an SGX-related option in the BIOS settings.

As a kernel, it's difficult to distinguish between the BIOS not
supporting SGX and the BIOS supporting SGX but it's disabled.

Therefore, update the error message to
'SGX disabled or unsupported by BIOS' to make it easier for those
reading kernel logs to understand what's happening.

Reported-by: Bo Wu <wubo@uniontech.com>
Closes: https://github.com/linuxdeepin/developer-center/issues/10032
Acked-by: Kai Huang <kai.huang@intel.com>
Link: https://lore.kernel.org/all/a30f7700c7817b3e7e2f2bdb37d5c10a318b2c3b.camel@intel.com/
Signed-off-by: Zelong Xiang <xiangzelong@uniontech.com>
Signed-off-by: WangYuli <wangyuli@uniontech.com>
---
 arch/x86/kernel/cpu/feat_ctl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/cpu/feat_ctl.c b/arch/x86/kernel/cpu/feat_ctl.c
index 1640ae76548f..4a4118784c13 100644
--- a/arch/x86/kernel/cpu/feat_ctl.c
+++ b/arch/x86/kernel/cpu/feat_ctl.c
@@ -188,7 +188,7 @@ void init_ia32_feat_ctl(struct cpuinfo_x86 *c)
 update_sgx:
 	if (!(msr & FEAT_CTL_SGX_ENABLED)) {
 		if (enable_sgx_kvm || enable_sgx_driver)
-			pr_err_once("SGX disabled by BIOS.\n");
+			pr_err_once("SGX disabled or unsupported by BIOS.\n");
 		clear_cpu_cap(c, X86_FEATURE_SGX);
 		return;
 	}
-- 
2.43.4

On Sun, 2024-08-25 at 16:17 +0800, WangYuli wrote:
> When SGX is not supported by the BIOS, the kernel log still output
> the error 'SGX disabled by BIOS', which can be confusing since
> there might not be an SGX-related option in the BIOS settings.
> 
> As a kernel, it's difficult to distinguish between the BIOS not
> supporting SGX and the BIOS supporting SGX but it's disabled.
> 
> Therefore, update the error message to
> 'SGX disabled or unsupported by BIOS' to make it easier for those
> reading kernel logs to understand what's happening.
> 
> Reported-by: Bo Wu <wubo@uniontech.com>
> Closes: https://github.com/linuxdeepin/developer-center/issues/10032
> Acked-by: Kai Huang <kai.huang@intel.com>
> Link: https://lore.kernel.org/all/a30f7700c7817b3e7e2f2bdb37d5c10a318b2c3b.camel@intel.com/
> Signed-off-by: Zelong Xiang <xiangzelong@uniontech.com>
> Signed-off-by: WangYuli <wangyuli@uniontech.com>

Hi Yuli,

When Thomas pointed out the "Signed-off-by chain is invalid" in v2:

https://lore.kernel.org/all/87zfpx4a0q.ffs@tglx/T/#mdc19b00c10177f3add9deaf505211bf8b3ec7110

I think it meant you either need to have a Co-developed-by for Zelong Xiang,
or you should remove his/her SoB.  The reason is the patch is from you, but
not Zelong.

The SoB chain needs to reflect the chronological history of this patch.  E.g.,
the SoB chain:

	From: You
	Co-developed-by: Zelong
	Signed-off-by: Zelong
	Signed-off-by: You

.. means the patch was originally generated by you, but Zelong also
participated in developing this patch before you finally signed off it.

For this one line code change patch, it doesn't make a lot sense to have
multiple developers, so I think you can just remove Zelong's SoB.

On 2024/8/25 16:49, Huang, Kai wrote:
> Hi Yuli,
>
> When Thomas pointed out the "Signed-off-by chain is invalid" in v2:
>
> https://lore.kernel.org/all/87zfpx4a0q.ffs@tglx/T/#mdc19b00c10177f3add9deaf505211bf8b3ec7110
>
> I think it meant you either need to have a Co-developed-by for Zelong Xiang,
> or you should remove his/her SoB.  The reason is the patch is from you, but
> not Zelong.
>
> The SoB chain needs to reflect the chronological history of this patch.

I get it now.

It's easy for this aspect to be overlooked or compromised when a patch 
is passed around among different developers.

Your rigorous approach is truly admirable.

>    E.g.,
> the SoB chain:
>
> 	From: You
> 	Co-developed-by: Zelong
> 	Signed-off-by: Zelong
> 	Signed-off-by: You
>
> .. means the patch was originally generated by you, but Zelong also
> participated in developing this patch before you finally signed off it.
>
> For this one line code change patch, it doesn't make a lot sense to have
> multiple developers, so I think you can just remove Zelong's SoB.

Since the goal is to ensure the SoB chain is as authentic as 
possible,there's no need to delete it unless the chain is unreasonably long.

I'll send a patch-v4 to fix it.


Thanks

-- 
WangYuli