All of lore.kernel.org
 help / color / mirror / Atom feed
From: david.vrabel@citrix.com (David Vrabel)
To: linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] [PATCH RFC] arm64: 32-bit tolerant sync bitops
Date: Thu, 17 Apr 2014 11:42:17 +0100	[thread overview]
Message-ID: <534FB009.5030904@citrix.com> (raw)
In-Reply-To: <1397723881-31648-1-git-send-email-murzin.v@gmail.com>

On 17/04/14 09:38, Vladimir Murzin wrote:
> Xen assumes that bit operations are able to operate on 32-bit size and
> alignment [1]. For arm64 bitops are based on atomic exclusive load/store
> instructions to guarantee that changes are made atomically. However, these
> instructions require that address to be aligned to the data size. Because, by
> default, bitops operates on 64-bit size it implies that address should be
> aligned appropriately. All these lead to breakage of Xen assumption for bitops
> properties.
> 
> With this patch 32-bit sized/aligned bitops is implemented. 
> 
> [1] http://www.gossamer-threads.com/lists/xen/devel/325613
> 
> Signed-off-by: Vladimir Murzin <murzin.v@gmail.com>
> ---
>  Apart this patch other approaches were implemented:
>  1. turn bitops to be 32-bit size/align tolerant.
>     the changes are minimal, but I'm not sure how broad side effect might be
>  2. separate 32-bit size/aligned operations.
>     it exports new API, which might not be good

I've never been particularly happy with the way the events_fifo.c uses
casts for the sync_*_bit() calls and I think we should do option 2.

A generic implementation could be something like:

bool sync_test_bit32(uint32_t *v, unsigned bit)
{
     if (sizeof(unsigned long) == 8 && (unsigned long)v & 0x4)
         return sync_test_bit((unsigned long *)(v - 1), bit + 32);
     else
         return sync_test_bit((unsigned long *)v, bit);
}

David

  parent reply	other threads:[~2014-04-17 10:42 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-17  8:38 [PATCH RFC] arm64: 32-bit tolerant sync bitops Vladimir Murzin
2014-04-17  8:41 ` [PATCH] xen: use sync_clear_bit instead of clear_bit Vladimir Murzin
2014-04-17 10:23   ` David Vrabel
2014-04-17 10:23   ` David Vrabel
2014-04-17  8:41 ` Vladimir Murzin
2014-04-17 10:42 ` David Vrabel [this message]
2014-04-21 16:18   ` [PATCH RFC] arm64: 32-bit tolerant sync bitops Vladimir Murzin
2014-04-21 16:18   ` [Xen-devel] " Vladimir Murzin
2014-04-22 10:16     ` David Vrabel
2014-04-22 10:16     ` [Xen-devel] " David Vrabel
2014-04-22 10:55       ` Ian Campbell
2014-04-22 10:55       ` Ian Campbell
2014-04-23  8:31   ` Ian Campbell
2014-04-23  8:31   ` [Xen-devel] " Ian Campbell
2014-04-22 20:56     ` Vladimir Murzin
2014-04-25  7:17       ` Ian Campbell
2014-04-25  8:43         ` Vladimir Murzin
2014-04-25  8:43         ` Vladimir Murzin
2014-04-25  7:17       ` Ian Campbell
2014-04-25  8:42       ` Vladimir Murzin
2014-04-25  8:42       ` [Xen-devel] " Vladimir Murzin
2014-04-22 20:56     ` Vladimir Murzin
2014-04-17 10:42 ` David Vrabel

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=534FB009.5030904@citrix.com \
    --to=david.vrabel@citrix.com \
    --cc=linux-arm-kernel@lists.infradead.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.