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.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel ard.biesheuvel@linaro.org ---
This applies in combination with Graeme's 'Platforms/ARM: Fix FVP FADT version'
Platforms/ARM/VExpress/AcpiTables/rtsm_ve-aemv8a/apic.asl | 116 ++++---------------- 1 file changed, 19 insertions(+), 97 deletions(-)
diff --git a/Platforms/ARM/VExpress/AcpiTables/rtsm_ve-aemv8a/apic.asl b/Platforms/ARM/VExpress/AcpiTables/rtsm_ve-aemv8a/apic.asl index 9cd303184352..7d915621efef 100644 --- a/Platforms/ARM/VExpress/AcpiTables/rtsm_ve-aemv8a/apic.asl +++ b/Platforms/ARM/VExpress/AcpiTables/rtsm_ve-aemv8a/apic.asl @@ -61,9 +61,9 @@ [0004] Performance Interrupt : 00000000 [0008] Parked Address : 0000000000000000 [0008] Base Address : 000000002C000000 /* armv8 FVP Base GIC address */ -[0008] Virtual GIC Base Address : 0 -[0008] Hypervisor GIC Base Address : 0 -[0004] Virtual GIC Interrupt : 0 +[0008] Virtual GIC Base Address : 000000002C02F000 +[0008] Hypervisor GIC Base Address : 000000002C010000 +[0004] Virtual GIC Interrupt : 00000019 [0008] Redistributor Base Address : 0 [0008] ARM MPIDR : 0 [0001] Efficiency Class : 00 @@ -82,9 +82,9 @@ [0004] Performance Interrupt : 00000000 [0008] Parked Address : 0000000000000000 [0008] Base Address : 000000002C000000 -[0008] Virtual GIC Base Address : 0 -[0008] Hypervisor GIC Base Address : 0 -[0004] Virtual GIC Interrupt : 0 +[0008] Virtual GIC Base Address : 000000002C02F000 +[0008] Hypervisor GIC Base Address : 000000002C010000 +[0004] Virtual GIC Interrupt : 00000019 [0008] Redistributor Base Address : 0 [0008] ARM MPIDR : 0000000000000001 [0001] Efficiency Class : 00 @@ -103,9 +103,9 @@ [0004] Performance Interrupt : 00000000 [0008] Parked Address : 0000000000000000 [0008] Base Address : 000000002C000000 -[0008] Virtual GIC Base Address : 0 -[0008] Hypervisor GIC Base Address : 0 -[0004] Virtual GIC Interrupt : 0 +[0008] Virtual GIC Base Address : 000000002C02F000 +[0008] Hypervisor GIC Base Address : 000000002C010000 +[0004] Virtual GIC Interrupt : 00000019 [0008] Redistributor Base Address : 0 [0008] ARM MPIDR : 0000000000000002 [0001] Efficiency Class : 00 @@ -124,103 +124,25 @@ [0004] Performance Interrupt : 00000000 [0008] Parked Address : 0000000000000000 [0008] Base Address : 000000002C000000 -[0008] Virtual GIC Base Address : 0 -[0008] Hypervisor GIC Base Address : 0 -[0004] Virtual GIC Interrupt : 0 +[0008] Virtual GIC Base Address : 000000002C02F000 +[0008] Hypervisor GIC Base Address : 000000002C010000 +[0004] Virtual GIC Interrupt : 00000019 [0008] Redistributor Base Address : 0 [0008] ARM MPIDR : 0000000000000003 [0001] Efficiency Class : 00 [0003] Reserved : 000000
-[0001] Subtable Type : 0B [Generic Interrupt Controller] -[0001] Length : 50 -[0002] Reserved : 0000 -[0004] CPU Interface Number : 00000004 -[0004] Processor UID : 00000004 -[0004] Flags (decoded below) : 00000001 - Processor Enabled : 1 - Performance Interrupt Trigger Mode : 0 - Virtual GIC Interrupt Trigger Mode : 0 -[0004] Parking Protocol Version : 00000000 -[0004] Performance Interrupt : 00000000 -[0008] Parked Address : 0000000000000000 -[0008] Base Address : 000000002C000000 -[0008] Virtual GIC Base Address : 0 -[0008] Hypervisor GIC Base Address : 0 -[0004] Virtual GIC Interrupt : 0 -[0008] Redistributor Base Address : 0 -[0008] ARM MPIDR : 0000000000000100 -[0001] Efficiency Class : 00 -[0003] Reserved : 000000 - -[0001] Subtable Type : 0B [Generic Interrupt Controller] -[0001] Length : 50 -[0002] Reserved : 0000 -[0004] CPU Interface Number : 00000005 -[0004] Processor UID : 00000005 -[0004] Flags (decoded below) : 00000001 - Processor Enabled : 1 - Performance Interrupt Trigger Mode : 0 - Virtual GIC Interrupt Trigger Mode : 0 -[0004] Parking Protocol Version : 00000000 -[0004] Performance Interrupt : 00000000 -[0008] Parked Address : 0000000000000000 -[0008] Base Address : 000000002C000000 -[0008] Virtual GIC Base Address : 0 -[0008] Hypervisor GIC Base Address : 0 -[0004] Virtual GIC Interrupt : 0 -[0008] Redistributor Base Address : 0 -[0008] ARM MPIDR : 0000000000000101 -[0001] Efficiency Class : 00 -[0003] Reserved : 000000 - -[0001] Subtable Type : 0B [Generic Interrupt Controller] -[0001] Length : 50 -[0002] Reserved : 0000 -[0004] CPU Interface Number : 00000006 -[0004] Processor UID : 00000006 -[0004] Flags (decoded below) : 00000001 - Processor Enabled : 1 - Performance Interrupt Trigger Mode : 0 - Virtual GIC Interrupt Trigger Mode : 0 -[0004] Parking Protocol Version : 00000000 -[0004] Performance Interrupt : 00000000 -[0008] Parked Address : 0000000000000000 -[0008] Base Address : 000000002C000000 -[0008] Virtual GIC Base Address : 0 -[0008] Hypervisor GIC Base Address : 0 -[0004] Virtual GIC Interrupt : 0 -[0008] Redistributor Base Address : 0 -[0008] ARM MPIDR : 0000000000000102 -[0001] Efficiency Class : 00 -[0003] Reserved : 000000 - -[0001] Subtable Type : 0B [Generic Interrupt Controller] -[0001] Length : 50 -[0002] Reserved : 0000 -[0004] CPU Interface Number : 00000007 -[0004] Processor UID : 00000007 -[0004] Flags (decoded below) : 00000001 - Processor Enabled : 1 - Performance Interrupt Trigger Mode : 0 - Virtual GIC Interrupt Trigger Mode : 0 -[0004] Parking Protocol Version : 00000000 -[0004] Performance Interrupt : 00000000 -[0008] Parked Address : 0000000000000000 -[0008] Base Address : 000000002C000000 -[0008] Virtual GIC Base Address : 0 -[0008] Hypervisor GIC Base Address : 0 -[0004] Virtual GIC Interrupt : 0 -[0008] Redistributor Base Address : 0 -[0008] ARM MPIDR : 0000000000000103 -[0001] Efficiency Class : 00 -[0003] Reserved : 000000 - [0001] Subtable Type : 0C [Generic Interrupt Distributor] [0001] Length : 18 [0002] Reserved : 0000 [0004] Local GIC Hardware ID : 00000000 [0008] Base Address : 000000002F000000 /* armv8 FVP Base GIC distributor base addr */ [0004] Interrupt Base : 00000000 -[0001] Version : 02 +[0001] Version : 03 [0003] Reserved : 000000 + +[0001] Subtable Type : 0E [Generic Interrupt Redistributor] +[0001] Length : 10 +[0002] Reserved : 0000 +[0008] Base Address : 000000002F100000 /* armv8 FVP Base GIC redistributor base addr */ +[0004] Region Size : 00200000
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?
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel ard.biesheuvel@linaro.org
This applies in combination with Graeme's 'Platforms/ARM: Fix FVP FADT version'
Platforms/ARM/VExpress/AcpiTables/rtsm_ve-aemv8a/apic.asl | 116 ++++---------------- 1 file changed, 19 insertions(+), 97 deletions(-)
diff --git a/Platforms/ARM/VExpress/AcpiTables/rtsm_ve-aemv8a/apic.asl b/Platforms/ARM/VExpress/AcpiTables/rtsm_ve-aemv8a/apic.asl index 9cd303184352..7d915621efef 100644 --- a/Platforms/ARM/VExpress/AcpiTables/rtsm_ve-aemv8a/apic.asl +++ b/Platforms/ARM/VExpress/AcpiTables/rtsm_ve-aemv8a/apic.asl @@ -61,9 +61,9 @@ [0004] Performance Interrupt : 00000000 [0008] Parked Address : 0000000000000000 [0008] Base Address : 000000002C000000 /* armv8 FVP Base GIC address */ -[0008] Virtual GIC Base Address : 0 -[0008] Hypervisor GIC Base Address : 0 -[0004] Virtual GIC Interrupt : 0 +[0008] Virtual GIC Base Address : 000000002C02F000 +[0008] Hypervisor GIC Base Address : 000000002C010000 +[0004] Virtual GIC Interrupt : 00000019 [0008] Redistributor Base Address : 0 [0008] ARM MPIDR : 0 [0001] Efficiency Class : 00 @@ -82,9 +82,9 @@ [0004] Performance Interrupt : 00000000 [0008] Parked Address : 0000000000000000 [0008] Base Address : 000000002C000000 -[0008] Virtual GIC Base Address : 0 -[0008] Hypervisor GIC Base Address : 0 -[0004] Virtual GIC Interrupt : 0 +[0008] Virtual GIC Base Address : 000000002C02F000 +[0008] Hypervisor GIC Base Address : 000000002C010000 +[0004] Virtual GIC Interrupt : 00000019 [0008] Redistributor Base Address : 0 [0008] ARM MPIDR : 0000000000000001 [0001] Efficiency Class : 00 @@ -103,9 +103,9 @@ [0004] Performance Interrupt : 00000000 [0008] Parked Address : 0000000000000000 [0008] Base Address : 000000002C000000 -[0008] Virtual GIC Base Address : 0 -[0008] Hypervisor GIC Base Address : 0 -[0004] Virtual GIC Interrupt : 0 +[0008] Virtual GIC Base Address : 000000002C02F000 +[0008] Hypervisor GIC Base Address : 000000002C010000 +[0004] Virtual GIC Interrupt : 00000019 [0008] Redistributor Base Address : 0 [0008] ARM MPIDR : 0000000000000002 [0001] Efficiency Class : 00 @@ -124,103 +124,25 @@ [0004] Performance Interrupt : 00000000 [0008] Parked Address : 0000000000000000 [0008] Base Address : 000000002C000000 -[0008] Virtual GIC Base Address : 0 -[0008] Hypervisor GIC Base Address : 0 -[0004] Virtual GIC Interrupt : 0 +[0008] Virtual GIC Base Address : 000000002C02F000 +[0008] Hypervisor GIC Base Address : 000000002C010000 +[0004] Virtual GIC Interrupt : 00000019 [0008] Redistributor Base Address : 0 [0008] ARM MPIDR : 0000000000000003 [0001] Efficiency Class : 00 [0003] Reserved : 000000
-[0001] Subtable Type : 0B [Generic Interrupt Controller] -[0001] Length : 50 -[0002] Reserved : 0000 -[0004] CPU Interface Number : 00000004 -[0004] Processor UID : 00000004 -[0004] Flags (decoded below) : 00000001
Processor Enabled : 1Performance Interrupt Trigger Mode : 0Virtual GIC Interrupt Trigger Mode : 0-[0004] Parking Protocol Version : 00000000 -[0004] Performance Interrupt : 00000000 -[0008] Parked Address : 0000000000000000 -[0008] Base Address : 000000002C000000 -[0008] Virtual GIC Base Address : 0 -[0008] Hypervisor GIC Base Address : 0 -[0004] Virtual GIC Interrupt : 0 -[0008] Redistributor Base Address : 0 -[0008] ARM MPIDR : 0000000000000100 -[0001] Efficiency Class : 00 -[0003] Reserved : 000000
-[0001] Subtable Type : 0B [Generic Interrupt Controller] -[0001] Length : 50 -[0002] Reserved : 0000 -[0004] CPU Interface Number : 00000005 -[0004] Processor UID : 00000005 -[0004] Flags (decoded below) : 00000001
Processor Enabled : 1Performance Interrupt Trigger Mode : 0Virtual GIC Interrupt Trigger Mode : 0-[0004] Parking Protocol Version : 00000000 -[0004] Performance Interrupt : 00000000 -[0008] Parked Address : 0000000000000000 -[0008] Base Address : 000000002C000000 -[0008] Virtual GIC Base Address : 0 -[0008] Hypervisor GIC Base Address : 0 -[0004] Virtual GIC Interrupt : 0 -[0008] Redistributor Base Address : 0 -[0008] ARM MPIDR : 0000000000000101 -[0001] Efficiency Class : 00 -[0003] Reserved : 000000
-[0001] Subtable Type : 0B [Generic Interrupt Controller] -[0001] Length : 50 -[0002] Reserved : 0000 -[0004] CPU Interface Number : 00000006 -[0004] Processor UID : 00000006 -[0004] Flags (decoded below) : 00000001
Processor Enabled : 1Performance Interrupt Trigger Mode : 0Virtual GIC Interrupt Trigger Mode : 0-[0004] Parking Protocol Version : 00000000 -[0004] Performance Interrupt : 00000000 -[0008] Parked Address : 0000000000000000 -[0008] Base Address : 000000002C000000 -[0008] Virtual GIC Base Address : 0 -[0008] Hypervisor GIC Base Address : 0 -[0004] Virtual GIC Interrupt : 0 -[0008] Redistributor Base Address : 0 -[0008] ARM MPIDR : 0000000000000102 -[0001] Efficiency Class : 00 -[0003] Reserved : 000000
-[0001] Subtable Type : 0B [Generic Interrupt Controller] -[0001] Length : 50 -[0002] Reserved : 0000 -[0004] CPU Interface Number : 00000007 -[0004] Processor UID : 00000007 -[0004] Flags (decoded below) : 00000001
Processor Enabled : 1Performance Interrupt Trigger Mode : 0Virtual GIC Interrupt Trigger Mode : 0-[0004] Parking Protocol Version : 00000000 -[0004] Performance Interrupt : 00000000 -[0008] Parked Address : 0000000000000000 -[0008] Base Address : 000000002C000000 -[0008] Virtual GIC Base Address : 0 -[0008] Hypervisor GIC Base Address : 0 -[0004] Virtual GIC Interrupt : 0 -[0008] Redistributor Base Address : 0 -[0008] ARM MPIDR : 0000000000000103 -[0001] Efficiency Class : 00 -[0003] Reserved : 000000
[0001] Subtable Type : 0C [Generic Interrupt Distributor] [0001] Length : 18 [0002] Reserved : 0000 [0004] Local GIC Hardware ID : 00000000 [0008] Base Address : 000000002F000000 /* armv8 FVP Base GIC distributor base addr */ [0004] Interrupt Base : 00000000 -[0001] Version : 02 +[0001] Version : 03 [0003] Reserved : 000000
+[0001] Subtable Type : 0E [Generic Interrupt Redistributor] +[0001] Length : 10 +[0002] Reserved : 0000 +[0008] Base Address : 000000002F100000 /* armv8 FVP Base GIC redistributor base addr */
+[0004] Region Size : 00200000
2.7.4
Linaro-uefi mailing list Linaro-uefi@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-uefi
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.
Alternatively, we could go back to different versions for FVP Foundation and FVP Base, but I was just trying to keep it simple.
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.
Alternatively, we could go back to different versions for FVP Foundation and FVP Base, but I was just trying to keep it simple.
I wouldn't want that. Too much hassle!
-- Ard.
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..
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.
Alternatively, we could go back to different versions for FVP Foundation and FVP Base, but I was just trying to keep it simple.
I wouldn't want that. Too much hassle!
-- Ard.
Linaro-uefi mailing list Linaro-uefi@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-uefi
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?
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.
Graeme
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.
-
Ard Biesheuvel -
G Gregory -
Jeremy Linton -
Ryan Harkin