在 2020/9/24 9:19, Huacai Chen 写道:
Hi, Jiaxun,
[...]
I'm just a little bit uncomfortable with this kind of hardcoded address.
Is it possible to generate kexec_smp_wait with uasm, or pass the SMP
base as a parameter of this function?
This is very difficult, and moreover, uasm wrap the assembly in C
functions, can it be more beautiful? In my opinion, uasm is only used
for performance-critical routines, not for beautiful code. But anyway,
0x900000003ff01000 should be improved.
Also I do think we can handle kexec_flag in Loongson's platform SMP,
or even generic MIPS SMP code just like what cavium did so this kind
of platform quirk can be avoided.
I doubt this can be done, every CPU has its own method of SMP bringup.
Hi Huacai,
I don't know kexec very well.. So please ignore my ideas if they're not
applicatable.
Hmm, as we've got control of all secondnary processors at the point, I
suspect
we can skip platform bring-up code.
Cavium makes use of secondary_kexec_args, can we do it as well?
I think kexec_flag was designed for this reason.
Current code is sending all secondnary processors to the entry point
of the new kernel, probably we can do something here.
I won't say it's safe.
Loongson-2K's PMON may place reboot vector here, also some
UEFI firmware may place their suspend stack here.
What if we allocate these buffer at runtime?
The layout of low 2MB in our design:
0x80000000 the first MB, the first 64K：Exception vector
0x80010000 the first MB, the second 64K：STR(suspend) data
0x80020000 the first MB, the third and fourth 64K：UEFI HOB
0x80040000 the first MB, the fifth 64K：RT-Thread for SMC
0x80100000 the second MB, the first 64K：KEXEC code
0x80108000 the second MB, the second 64K：KEXEC data
Well, there are some other vendors violating this design.
Especially for embedded systems like Loongson-2K.
All allocated buffer from the old kernel is not safe, because the new
kernel may be larger than the old kernel. Even if the low 2MB is not a
perfect place, it is the best place we can choose.
Oops I ignored overlapping..
Then it looks fine for me..
Thanks.
- Jiaxun
Huacai
Thanks.
- Jiaxun
_______________________________________________
kexec mailing list
kexec@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/kexec
