On 4 July 2016 at 10:18, G Gregory graeme.gregory@linaro.org wrote:
On Fri, Jul 01, 2016 at 09:55:47PM +0200, Ard Biesheuvel wrote:
On 1 July 2016 at 21:50, Jeremy Linton jeremy.linton@arm.com wrote:
On 06/28/2016 10:35 AM, Ryan Harkin wrote:
On 28 June 2016 at 15:03, Ard Biesheuvel ard.biesheuvel@linaro.org wrote:
On 24 June 2016 at 18:37, Ryan Harkin ryan.harkin@linaro.org wrote:
On 24 June 2016 at 11:29, Ard Biesheuvel ard.biesheuvel@linaro.org wrote: > > This upgrades the MADT table so that it exposes the GIC as a v3. The > virtual base address and interrupt, and the hypervisor base address are > corrected as well. > > Since the Foundation model has 4 cores at the most, and since > refactoring > this code to update the ACPI tables dynamically based on the actual > core > count is more trouble that its worth, remove the second cluster while > we > are at it.
I know I said I wasn't bothered about ACPI, and I'm not, but doesn't the AEMv8 model have 2 clusters of 4 cpus?
At the most, yes. My assumption is that the overhead of having the firmware figure this out at runtime, and patch the ACPI tables accordingly is not worth the trouble. FVP Base can run fine with 4 CPUs (or only one), so it is simply a matter of choosing a reasonable sweet spot.
Fair enough, I have no objection to that. I was mostly thinking about the DTB: people decided the kernel runs fine if the extra CPUs are missing in the model, so it has 8 CPUs and Foundation just runs without them.
I haven't had a chance to test this patch, but I imagine if everything is working ok the same thing should happen with ACPI. If there are only 4 cores, and the MADT has 8 then they just fail to come online and the kernel prints some ugly messages but everything works..
Indeed.
Really, we should be marking the unused ones offline and setting the GIC version in the table (eventually based on the command line parms). Something like Vlv2TbltDevicePkg/AcpiPlatform/AcpiPlatform.c PlatformUpdateTables() seems like a good starting point. Its fairly common (and might actually be required, I should check the spec) to allocate table entries for future/hotplug cpus in the MADT and just leave them offline.
We have code already that detects the GIC version in the FVP platform: we use it to select the DTB blob if the image has any built in. So it should be fairly easy to use the same information to set the GIC version.
Obtaining the core count is not that straightforward, I'm afraid.
I can have a stab at implementing this, but that would require switching to .aslc format first. @Graeme: any updates there?
Not yet, sprint flu hit me hard this time round. On my plans to tackle this week.
OK, so after trying Graeme's patches, which already switches FVP to GICv3, I think it makes sense to drop this patch. As Jeremy points out, we can simply keep the description of two clusters with four cores each, and ignore the errors in the kernel log when the model was started with fewer CPUs. And given that ARM Trusted Firmware now requires FVP to have a GICv3 on the secure side, we can no longer drive it as a v2 on the non-secure side even if we wanted to unless we use a custom build of ATF.
So I'm dropping this patch.
Thanks, Ard.