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

From: Tamas K Lengyel <tamas@tklengyel.com>
To: Michal Orzel <michal.orzel@arm.com>
Cc: Julien Grall <julien@xen.org>,
	Xen-devel <xen-devel@lists.xenproject.org>,
	 Stefano Stabellini <sstabellini@kernel.org>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>,
	 Alexandru Isaila <aisaila@bitdefender.com>,
	Petre Pircalabu <ppircalabu@bitdefender.com>,
	 bertrand.marquis@arm.com
Subject: Re: [PATCH v2 10/10] arm64: Change type of hsr, cpsr, spsr_el1 to uint64_t
Date: Thu, 29 Apr 2021 06:31:25 -0400	[thread overview]
Message-ID: <CABfawhndnBQZtiRXXy_Xys5LWDqmz1VaquMxTPBY2ii+d8ATEQ@mail.gmail.com> (raw)
In-Reply-To: <0c90579b-4861-8f90-2978-9e7f9015fae3@arm.com>

[-- Attachment #1: Type: text/plain, Size: 5426 bytes --]

On Thu, Apr 29, 2021, 4:53 AM Michal Orzel <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>
> >> 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.

Thanks,
Tamas

>

[-- Attachment #2: Type: text/html, Size: 7112 bytes --]