Hi Salil,
On 02/09/2022 11:04, Salil Mehta wrote:
Above check will return "cpu is usable" even for Enabled=true && online-capable=true (INVALID Case)?
Yes. Why should linux sanity check the ACPI tables?
To ensure that other two fields which Linux wants to use are correct, which partly above code is already doing but there is an ambiguity.
In this case, trying to do this just results in harder to read code. What is the benefit?
This code is common to all ARM64 based platforms but BIOS are specific to platforms and sometimes can be buggy. This little extra piece of logic can really save lots of hours of that poor fellow working onsite who is trying to figure out why things are not working when there is no error being purged out in UEFI/Linux at bootup.
Usually, everything we do should be customer driven and should facilitate ease of doing business(here, deployment of particular software using vCPU Hotplug say microvms?)
In my humble opinion, above reason will always outweigh maintainability, though I agree that there is a balance to that as well. But then later is not exactly true in this particular case since amount of code being added is very trivial but has huge end user gains.
I very much doubt that combination can be used for anything that implies the CPU can't be used.
This is the precise ambiguity we can clear if we can put a harmless print to assist the code reviewer and the end user?
Both zero is valid - it means the CPU can't be used. I don't think we should print about disabled cpus that are found in the MADT.
If Enabled is set, 'Online Capable' is reserved. We don't know that it won't be allocated in the future. Once it is, all previous kernels will be printing a snotty message about this bit being set, even though it may have a valid meaning. I don't think linux should try to validate the ACPI tables.
I can change the check to logical-xor instead of logical-or, but its harder to read, and I don't think it buys us anything.
In the cases where there are problems with the table, e.g. the redistributors are described in the GICC not the GICR, (so the power-domain isn't known), a warning is printed to try and help in the scenario you describe. I think this is a different case as the OS making a decision not to use the information in the table.
Thanks,
James