Skip to contentSkip to conversation

Warning on SME when manually onlining CPUs late.

DISCUSSION Jonathan Cameron 3 participants 3 messages Jul 27, 2023

lore
Share & tools
lore
#0 lore raw

Hi Mark

Hit this due to a silly config error on a QEMU TCG test but seemed worth asking about as I'm buried in other stuff and no time to investigate further for a few weeks.

Test probably could be simplified but it's more or less vanilla upstream QEMU with -cpu max -smp 8 and kernel command line with maxcpus=4

echo 1 > /sys/bus/cpu/devices/cpu4/online

CPU features: SANITY CHECK: Unexpected variation in SYS_SMCR_EL1. Boot CPU: 0x0000000000000f, CPU4: 0x0000008000000f CPU features: Unsupported CPU feature variation detected.

If this is already well known, then sorry for noise. I've not been paying much attention to the SME work.

Looks like the FA64 bit isn't set for the CPU state of the boot CPU that is being compared
- I guess a stale record somewhere being used for the comparison?

Could be an issue on QEMU side I guess - though from a quick look it all seemed to be correct there. Just in case +CC Richard.

Jonathan

_______________________________________________
linux-arm-kernel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

#1 lore raw
Quoted 13 lines · Jonathan Cameron

Hi Mark

Hit this due to a silly config error on a QEMU TCG test but seemed worth asking about as I'm buried in other stuff and no time to investigate further for a few weeks.

Test probably could be simplified but it's more or less vanilla upstream QEMU with -cpu max -smp 8 and kernel command line with maxcpus=4

echo 1 > /sys/bus/cpu/devices/cpu4/online

CPU features: SANITY CHECK: Unexpected variation in SYS_SMCR_EL1. Boot CPU: 0x0000000000000f, CPU4: 0x0000008000000f CPU features: Unsupported CPU feature variation detected.

Quoted 8 lines

If this is already well known, then sorry for noise. I've not been paying much attention to the SME work.

Looks like the FA64 bit isn't set for the CPU state of the boot CPU that is being compared
- I guess a stale record somewhere being used for the comparison?

Could be an issue on QEMU side I guess - though from a quick look it all seemed to be correct there. Just in case +CC Richard.

SMCR_EL1 is for the OS to configure -- if they have different values then that's a kernel bug. I wouldn't expect this to be a QEMU problem.

r~

_______________________________________________
linux-arm-kernel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel