[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: Stefano Stabellini <sstabellini@xxxxxxxxxx>
  • From: Bertrand Marquis <Bertrand.Marquis@xxxxxxx>
  • Date: Thu, 24 Mar 2022 08:31:14 +0000
  • Accept-language: en-GB, en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=GL8+C0DxIO2X9JEoO0P5jNQzjHBJ9Ntm6OSL0/ylPX4=; b=BC9kU7VtdoshVftVG4fpV7eDSDJNrR7sr6L6uzQnhWG5m1NK8HOd/UVJKegKaTjsM8DTdpKlKDIUPEmqCkcFVe7WX/qZtO+T2yfNIG2EtSkwhm6Bfu2HKyXh6/vjdMI15CSF2K6DFD6COBr1D8LOjxdd2EWdNgbchwQu3gso1EX19gNoZPC8utDypOUa1lwGm5Oa33WDI8CzpqmQF0G6zr/xCAJDSufGP//M8TSO4tcREtqfZOy9fPOl3BqOiFgdhntfMlDeenSVkbklzGkskbzWW/wNyVt8jyU3HYMOeFp8eO11McFBH31kZMuvta0892hVWuP0Wn/aStSyuPp1hQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hD+KkdG1gtXvwNlEYOR2Fng02VYkGCU1FUUaLh/SypMyvPK35vIfXJK/0thhnKYYqprEzKFBVcrV17nSiq6oocKBAagc3jxWwWDFzYVqccvhmIlOGDj9a6QVgIPeNLvnhPkrWWCZ0Ry+80wiJHM59pUGuhrdbegTqpYVVBwzc+ROmRmf6whJWdrkrCD5DmxodK8z3iSXbQGzrP+9xwZyfZwSe7jVAhoV1UWk0tFHLG/HsQRVITbJDD1kc33ihPQNXT5mLapZNQaA3HSb9A7fU2Pz5ma2P1KIH1TgrJBakZ6Fgt6YzL5PWmUXSAoFh9ZNfQj/PWcm5FdPi2nPpeeqAg==
  • Authentication-results-original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, "julien@xxxxxxx" <julien@xxxxxxx>, "Volodymyr_Babchuk@xxxxxxxx" <Volodymyr_Babchuk@xxxxxxxx>, Stefano Stabellini <stefano.stabellini@xxxxxxxxxx>
  • Delivery-date: Thu, 24 Mar 2022 08:31:37 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Nodisclaimer: true
  • Original-authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
  • Thread-index: AQHYPittA0qvCk1VqUeT+Og+1zrr1azMqmOAgAEgdgCAAGvcAA==
  • Thread-topic: [PATCH v2] xen/arm: set CPSR Z bit when creating aarch32 guests

Hi Stefano,

Thanks a lot for the detailed answers.

> On 24 Mar 2022, at 03:05, Stefano Stabellini <sstabellini@xxxxxxxxxx> wrote:
> 
> On Wed, 23 Mar 2022, Bertrand Marquis wrote:
>>> On 22 Mar 2022, at 21:28, Stefano Stabellini <sstabellini@xxxxxxxxxx> 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.
>>> 
>>> All kernel releases starting from Linux 4.9 without commit a92882a4d270
>>> are affected.
>> 
>> Can you confirm if those kernels are also affected when started natively ?
> 
> Theoretically yes, but in practice only booting on Xen is affected
> because:
> 
> - the issue cannot happen when booting from u-boot because u-boot sets
>  the "Z" bit
> - the issue cannot happen when booting with QEMU -kernel because it also
>  sets "Z"
> - older bootloaders on native skip the first 32 bytes of the start
>  address, which also masks this problem
> 
> Thus, in practice, I have no idea how one could reproduce the problem on
> native.
> 
> This info is in the commit message a92882a4d270 on Linux and in-code
> comments in the kernel.

If uboot is setting we can consider that we have a behaviour equivalent to
a native boot.
Could you add something in the comment in your patch to state that the Z
flag is also set by uboot ?
This will help in the future to remember why it is ok to have that as the
current comment could make one think that this is something only done by
Xen.

> 
> 
>>> 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 agree with Jan here. This will never be set or should not be expected
>> to be set by anyone when started.
>> It feels to me that we are introducing an ack for a temporary issue in
>> Linux which will makes us derive from the behaviour that could be
>> expected on native hardware.
>> 
>> Could you give more details on how blocking this is ? 
> 
> Without this change, none of the Debian arm32 kernels boot on Xen after
> Jessie (on QEMU).

Ok

> 
> 
>> Is the kernel update with the fix available on any of the affected 
>> distributions ?
> 
> None that I could find. I tried Debian Buster, Debian Bullseye, Debian
> testing and the latest Alpine Linux. Happy to try more if you give me a
> download link or two.

I think the list is long enough to justify the change.

> 
> 
>> Depending on the answers I think we could for example have a config around
>> this to flag it as workaround for a specific guest issue so that this is only
>> activated when needed.
> 
> Also note that this alternative workaround also solves the problem,
> however it has other drawbacks as Julien described:
> [1] https://marc.info/?l=xen-devel&m=164774063802402

Definitely setting the Z bit is better I think.

> 
> 
> My take on this is the following. PSR_GUEST32_INIT is not part of the
> ABI so this cannot be considered an ABI change.
> 
> But in any case, given that without this change (or another change [1])
> most of the kernels out there don't work, is there a point in discussing
> ABI breakages? Basically nothing works right now :-D
> 
> I think it makes sense to think whether this change could cause a kernel
> that used to boot, not to boot anymore. However, I don't think is
> possible because:
> 
> - we only support zImage on arm32 and "Z" works well with it
> - both u-boot and qemu -kernel set "Z" so we would already now if
>  something broke
> 

Agree so please add that both in the comment and in the commit message.

Cheers
Bertrand

> 
> 
>>> Signed-off-by: Stefano Stabellini <stefano.stabellini@xxxxxxxxxx>
>>> ---
>>> Changes in v2:
>>> - improve commit message
>>> - add in-code comment
>>> - move PSR_Z to the beginning
>>> ---
>>> xen/include/public/arch-arm.h | 8 +++++++-
>>> 1 file changed, 7 insertions(+), 1 deletion(-)
>>> 
>>> diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
>>> index 94b31511dd..81cee95f14 100644
>>> --- a/xen/include/public/arch-arm.h
>>> +++ b/xen/include/public/arch-arm.h
>>> @@ -361,6 +361,7 @@ typedef uint64_t xen_callback_t;
>>> #define PSR_DBG_MASK    (1<<9)        /* arm64: Debug Exception mask */
>>> #define PSR_IT_MASK     (0x0600fc00)  /* Thumb If-Then Mask */
>>> #define PSR_JAZELLE     (1<<24)       /* Jazelle Mode */
>>> +#define PSR_Z           (1<<30)       /* Zero condition flag */
>>> 
>>> /* 32 bit modes */
>>> #define PSR_MODE_USR 0x10
>>> @@ -383,7 +384,12 @@ typedef uint64_t xen_callback_t;
>>> #define PSR_MODE_EL1t 0x04
>>> #define PSR_MODE_EL0t 0x00
>>> 
>>> -#define PSR_GUEST32_INIT  
>>> (PSR_ABT_MASK|PSR_FIQ_MASK|PSR_IRQ_MASK|PSR_MODE_SVC)
>>> +/*
>>> + * We set PSR_Z to be able to boot Linux kernel versions with an invalid
>>> + * encoding of the first 8 NOP instructions. See commit a92882a4d270 in
>>> + * Linux.
>>> + */
>>> +#define PSR_GUEST32_INIT  
>>> (PSR_Z|PSR_ABT_MASK|PSR_FIQ_MASK|PSR_IRQ_MASK|PSR_MODE_SVC)
>>> #define PSR_GUEST64_INIT 
>>> (PSR_ABT_MASK|PSR_FIQ_MASK|PSR_IRQ_MASK|PSR_MODE_EL1h)
>>> 
>>> #define SCTLR_GUEST_INIT    xen_mk_ullong(0x00c50078)
>>> -- 
>>> 2.25.1
>>> 
>> 




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.