Re: [PATCH v2] xen/arm: set CPSR Z bit when creating aarch32 guests

[Jan Beulich <jbeulich@xxxxxxxx>]

On 22.03.2022 21:28, Stefano Stabellini wrote:
> From: Stefano Stabellini <stefano.stabellini@xxxxxxxxxx>
> 
> The first 32 bytes of zImage are NOPs. When CONFIG_EFI is enabled in the
> kernel, certain versions of Linux will use an UNPREDICATABLE NOP
> encoding, sometimes resulting in an unbootable kernel. Whether the
> resulting kernel is bootable or not depends on the processor. See commit
> a92882a4d270 in the Linux kernel for all the details.

Is this a problem only under Xen or also on bare hardware? In the
latter case I'd be even more inclined to require this issue to be
dealt with in the kernels, rather than working around it by an ABI
change in Xen.

> All kernel releases starting from Linux 4.9 without commit a92882a4d270
> are affected.
> 
> Fortunately there is a simple workaround: setting the "Z" bit in CPSR
> make it so those invalid NOP instructions are never executed. That is
> because the instruction is conditional (not equal). So, on QEMU at
> least, the instruction will end up to be ignored and not generate an
> exception. Setting the "Z" bit makes those kernel versions bootable
> again and it is harmless in the other cases.

I'm afraid such an ABI change being harmless needs to be not just
claimed, but proven. There could certainly be reasons this is safe,
e.g. the same path being taken on bare hardware, and the state of
the bit not being specified there. Yet even in presence of such a
specification it cannot be excluded that non-standard (something
XTF-like, for example) uses might have grown a dependency on the
Xen ABI specification.

Jan