Re: [PATCH v2 10/10] arm64: Change type of hsr, cpsr, spsr_el1 to uint64_t

[Julien Grall <julien@xen.org>]

On 29/04/2021 11:31, Tamas K Lengyel wrote:
> On Thu, Apr 29, 2021, 4:53 AM Michal Orzel <michal.orzel@arm.com 
> <mailto:michal.orzel@arm.com>> wrote:
> 
>     Hi Julien,
> 
>     On 27.04.2021 13:09, Julien Grall wrote:
>      > Hi Michal,
>      >
>      > On 27/04/2021 10:35, Michal Orzel wrote:
>      >> AArch64 registers are 64bit whereas AArch32 registers
>      >> are 32bit or 64bit. MSR/MRS are expecting 64bit values thus
>      >> we should get rid of helpers READ/WRITE_SYSREG32
>      >> in favour of using READ/WRITE_SYSREG.
>      >> We should also use register_t type when reading sysregs
>      >> which can correspond to uint64_t or uint32_t.
>      >> Even though many AArch64 registers have upper 32bit reserved
>      >> it does not mean that they can't be widen in the future.
>      >>
>      >> Modify type of hsr, cpsr, spsr_el1 to uint64_t.
>      >
>      > As I pointed out in v1, the access to SPSR_EL1 has been quite
>     fragile because we relied on the padding afterwards. I think this
>     was ought to be explain in the commit message because it explain why
>     the access in the assembly code is not modified.
>      >
>     How about:
>     "
>     Modify type of hsr, cpsr, spsr_el1 to uint64_t.
>     Previously we relied on the padding after SPSR_EL1. As we removed
>     the padding, modify the union to be 64bit
>     so we don't corrupt SPSR_FIQ.
>     No need to modify the assembly code becuase the accesses were based
>     on 64bit registers as there was a 32bit padding after SPSR_EL1.
>     "
>      >>
>      >> Add 32bit RES0 members to structures inside hsr union.
>      >>
>      >> Remove 32bit padding in cpu_user_regs before spsr_fiq
>      >> as it is no longer needed due to upper union being 64bit now.
>      >>
>      >> Add 64bit padding in cpu_user_regs before spsr_el1
>      >> because offset of spsr_el1 must be a multiple of 8.
>      >>
>      >> Signed-off-by: Michal Orzel <michal.orzel@arm.com
>     <mailto:michal.orzel@arm.com>>
>      >> diff --git a/xen/include/asm-arm/hsr.h b/xen/include/asm-arm/hsr.h
>      >> index 29d4531f40..fb4a3b1274 100644
>      >> --- a/xen/include/asm-arm/hsr.h
>      >> +++ b/xen/include/asm-arm/hsr.h
>      >> @@ -16,11 +16,12 @@ enum dabt_size {
>      >>   };
>      >>     union hsr {
>      >> -    uint32_t bits;
>      >> +    register_t bits;
>      >>       struct {
>      >>           unsigned long iss:25;  /* Instruction Specific Syndrome */
>      >>           unsigned long len:1;   /* Instruction length */
>      >>           unsigned long ec:6;    /* Exception Class */
>      >> +        unsigned long _res0:32;
>      >
>      > Sorry I wasn't clear in my original comment, what I meant I would
>     rather not add this field (and also the _res0) because they are not
>     strictly necessary.
>      >
>     Ok I'll remove _res0 members. But bits can be of type register_t, right?
>      >> diff --git a/xen/include/public/arch-arm.h
>     b/xen/include/public/arch-arm.h
>      >> index 713fd65317..c49bce2983 100644
>      >> --- a/xen/include/public/arch-arm.h
>      >> +++ b/xen/include/public/arch-arm.h
>      >> @@ -267,10 +267,10 @@ struct vcpu_guest_core_regs
>      >>         /* Return address and mode */
>      >>       __DECL_REG(pc64,         pc32);             /* ELR_EL2 */
>      >> -    uint32_t cpsr;                              /* SPSR_EL2 */
>      >> +    register_t cpsr;                            /* SPSR_EL2 */
>      >
>      > You can't use register_t here because this is a public header (we
>     don't export register_t) and the header should be bitness agnostic.
>      >
>      > Also, because this is a public header, you ought to explain why
>     breaking the ABI is fine.
>      >
>      > In this case, this is an ABI between the tools and this is not
>     stable. However, we would still need to bump
>     XEN_DOMCTL_INTERFACE_VERSION as I think this wasn't done for this
>     development cycle.
>      >
>      > Of course, this will also need a suitable mention in the commit
>     message (I can help with that).
>      >
>     Ok so I'll increment XEN_DOMCTL_INTERFACE_VERSION and write in
>     commit msg:
>     "
>     Change type of cpsr to uint64_t in the public outside interface
>     "public/arch-arm.h" to allow ABI compatibility between 32bit and 64bit.
>     Increment XEN_DOMCTL_INTERFACE_VERSION.
>     "
>      >>         union {
>      >> -        uint32_t spsr_el1;       /* AArch64 */
>      >> +        uint64_t spsr_el1;       /* AArch64 */
>      >>           uint32_t spsr_svc;       /* AArch32 */
>      >>       };
>      >>   diff --git a/xen/include/public/vm_event.h
>     b/xen/include/public/vm_event.h
>      >> index 36135ba4f1..ad3d141fe8 100644
>      >> --- a/xen/include/public/vm_event.h
>      >> +++ b/xen/include/public/vm_event.h
>      >> @@ -266,8 +266,12 @@ struct vm_event_regs_arm {
>      >>       uint64_t ttbr1;
>      >>       uint64_t ttbcr;
>      >>       uint64_t pc;
>      >> +#ifdef CONFIG_ARM_32
>      >>       uint32_t cpsr;
>      >>       uint32_t _pad;
>      >> +#else
>      >> +    uint64_t cpsr;
>      >> +#endif
>      >
>      > CONFIG_ARM_32 is not defined for public header. They also should
>     be bitness agnostic. So cpsr should always be uint64_t.
>      >
>      > Also, similar to public/arch-arm.h, this is not a stable ABI but
>     you will need to bump VM_EVENT_INTERFACE_VERSION if this hasn't been
>     done for this development cycle.
>      >
>     Ok so I will change type of cpsr here to uint64_t, increment
>     VM_EVENT_INTERFACE_VERSION and write in commit msg:
>     "
>     Change type of cpsr to uint64_t in the public outside interface
>     "public/vm_event.h" to allow ABI compatibility between 32bit and 64bit.
>     Increment VM_EVENT_INTERFACE_VERSION.
>     "
>     Ok?
> 
> 
> There is no need to bump the interface version for this, you are not 
> changing the layout or size of the structure since there was already 
> 64bit space there for cspr for both 32bit and 64bit builds. You are just 
> folding that padding field into cspr on 32bit builds.

Ah I didn't realize the padding was already there. Although, is it 
always zeroed?

If not, then this is would technically be an ABI breakage if you build a 
vm event tool using public/vm_event.h from Xen 4.16 and use it on Xen 4.15.

Cheers,

-- 
Julien Grall