All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ayan Kumar Halder <ayankuma@amd.com>
To: Julien Grall <julien@xen.org>,
	Ayan Kumar Halder <ayan.kumar.halder@amd.com>,
	xen-devel@lists.xenproject.org
Cc: sstabellini@kernel.org, stefanos@xilinx.com,
	Volodymyr_Babchuk@epam.com, bertrand.marquis@arm.com,
	michal.orzel@amd.com
Subject: Re: [XEN v2] xen/Arm: Enforce alignment check for atomic read/write
Date: Mon, 7 Nov 2022 10:36:03 +0000	[thread overview]
Message-ID: <33a2d125-b7f2-3637-9dab-6b7d616fd4ff@amd.com> (raw)
In-Reply-To: <062c9507-7744-0742-effb-76d2f1222a27@xen.org>


On 06/11/2022 17:54, Julien Grall wrote:
> Hi Ayan,

Hi Julien,

I need some clarification.

>
> To me the title and the explaination below suggests...
>
> On 04/11/2022 16:23, Ayan Kumar Halder wrote:
>> From: Ayan Kumar Halder <ayankuma@amd.com>
>>
>> Refer ARM DDI 0487I.a ID081822, B2.2.1
>> "Requirements for single-copy atomicity
>>
>> - A read that is generated by a load instruction that loads a single
>> general-purpose register and is aligned to the size of the read in the
>> instruction is single-copy atomic.
>>
>> -A write that is generated by a store instruction that stores a single
>> general-purpose register and is aligned to the size of the write in the
>> instruction is single-copy atomic"
>>
>> On AArch32, the alignment check is enabled at boot time by setting 
>> HSCTLR.A bit.
>> ("HSCTLR, Hyp System Control Register").
>> However in AArch64, alignment check is not enabled at boot time.
>
> ... you want to enable the alignment check on AArch64 always. 

I want to enable alignment check *only* for atomic access.

May be I should remove this line --> "However in AArch64, alignment 
check is not enabled at boot time.".

> However, this is not possible to do because memcpy() is using 
> unaligned access.
This is a non atomic access. So the commit does not apply here.
>
> I think the commit message/title should clarify that the check is 
> *only* done during debug build. IOW, there are no enforcement in 
> producation build.

AFAICS read_atomic()/write_atomic() is enabled during non debug builds 
(ie CONFIG_DEBUG=n) as well.

For eg :- vgic_v3_distr_mmio_read() --> vgic_fetch_irouter() --> 
read_atomic() . There is no check for CONFIG_DEBUG.

- Ayan

>
> The alternative would be to use a BUG_ON() but that might be too high 
> overhead.
>
> Cheers,
>
>>
>> Thus, one needs to check for alignment when performing atomic 
>> operations.
>>
>> Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
>> Reviewed-by: Michal Orzel <michal.orzel@amd.com
>> ---
>>
>> Changes from :-
>> v1 - 1. Referred to the latest Arm Architecture Reference Manual in 
>> the commit
>> message.
>>
>>   xen/arch/arm/include/asm/atomic.h | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/xen/arch/arm/include/asm/atomic.h 
>> b/xen/arch/arm/include/asm/atomic.h
>> index 1f60c28b1b..64314d59b3 100644
>> --- a/xen/arch/arm/include/asm/atomic.h
>> +++ b/xen/arch/arm/include/asm/atomic.h
>> @@ -78,6 +78,7 @@ static always_inline void read_atomic_size(const 
>> volatile void *p,
>>                                              void *res,
>>                                              unsigned int size)
>>   {
>> +    ASSERT(IS_ALIGNED((vaddr_t)p, size));
>>       switch ( size )
>>       {
>>       case 1:
>> @@ -102,6 +103,7 @@ static always_inline void 
>> write_atomic_size(volatile void *p,
>>                                               void *val,
>>                                               unsigned int size)
>>   {
>> +    ASSERT(IS_ALIGNED((vaddr_t)p, size));
>>       switch ( size )
>>       {
>>       case 1:
>


  reply	other threads:[~2022-11-07 10:36 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-04 16:23 [XEN v2] xen/Arm: Enforce alignment check for atomic read/write Ayan Kumar Halder
2022-11-04 16:32 ` Bertrand Marquis
2022-11-06 17:54 ` Julien Grall
2022-11-07 10:36   ` Ayan Kumar Halder [this message]
2022-11-07 10:44     ` Julien Grall
2022-11-07 12:49       ` Ayan Kumar Halder
2022-11-07 18:06         ` Julien Grall
2022-11-08  7:26           ` Michal Orzel
2022-11-08  8:34             ` Bertrand Marquis
2022-11-08  9:48               ` Ayan Kumar Halder

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=33a2d125-b7f2-3637-9dab-6b7d616fd4ff@amd.com \
    --to=ayankuma@amd.com \
    --cc=Volodymyr_Babchuk@epam.com \
    --cc=ayan.kumar.halder@amd.com \
    --cc=bertrand.marquis@arm.com \
    --cc=julien@xen.org \
    --cc=michal.orzel@amd.com \
    --cc=sstabellini@kernel.org \
    --cc=stefanos@xilinx.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.