On Wed, May 11, 2016 at 11:50:36AM +0200, Igor Mammedov wrote:
On Tue, 10 May 2016 16:43:34 +0200 Igor Mammedov imammedo@redhat.com wrote:
MaxCountCPUs could never be 0 or less CountCPUs anymore, remove code that wouldn't be executed.
Signed-off-by: Igor Mammedov imammedo@redhat.com
src/fw/smp.c | 2 -- 1 file changed, 2 deletions(-)
diff --git a/src/fw/smp.c b/src/fw/smp.c index 18a4c77..4d82502 100644 --- a/src/fw/smp.c +++ b/src/fw/smp.c @@ -175,8 +175,6 @@ smp_setup(void) *(u64*)BUILD_AP_BOOT_ADDR = old;
Also looking at usage of BUILD_AP_BOOT_ADDR, it doesn't seem to user anywhere beside of smp_setup() and smp_setup every time overwrites it to point to entry_smp trampoline So saving/restoring 'old' value doesn't look like necessary, should it be cleaned up as well?
That's in there because technically malloc_tmplow() could give out that address range (see alloc_add(&ZoneTmpLow) in malloc_preinit). So, the idea is to save/restore the area so that the trampoline doesn't alter anything stored there. In practice nothing that early in the boot would use enough malloc_tmplow space to give out that address, but it doesn't hurt to save/restore either.
handle_x2apic();
- if (!MaxCountCPUs || MaxCountCPUs < CountCPUs)
MaxCountCPUs = CountCPUs;
BTW, the "MaxCountCPUs < CountCPUs" check was in there for really old versions of QEMU that didn't populate "etc/max-cpus". Unless you're sure that "etc/max-cpus" predates CMOS_BIOS_SMP_COUNT, I'd be inclined to leave the check in there. (No need to resend the series if not sure).
-Kevin