On 13/01/2020 17:50, Andrew Cooper wrote:
> It turns out that the note in c/s a8d27a54cc9cc
>
> Finally, leave a linker assert covering the fact that plenty of code blindly
> assumes that Xen is less that 16M. This wants fixing in due course.
>
> was easier to address than I had originally anticipated. This series does so.
>
> The end result can be tested by trying to boot with:
>
> diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
> index 759827a19a..fa83a9a28f 100644
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -52,6 +52,8 @@
> #include <asm/spec_ctrl.h>
> #include <asm/guest.h>
>
> +static uint8_t __used big_data[MB(16)] = { 42, };
> +
> /* opt_nosmp: If true, secondary processors are ignored. */
> static bool __initdata opt_nosmp;
> boolean_param("nosmp", opt_nosmp);
>
> Before this series, Xen will triple fault in one of several places (first and
> most obviously, __high_start on the first stack access, as cpu0_stack[] is
> very near the end of Xen's linked image).
It turns out this is incomplete. I've found another hardcoded 16M
intertwined with the trampoline relocation logic.
The code presented here is fine and ready for submission, with the
exception of the hunk in the final patch which drops the linker assertion.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
