Re: [Xen-devel] [PATCH] xen/arm64: disable alignment check

[Vladimir Murzin <murzin.v@xxxxxxxxx>]

On Mon, Apr 28, 2014 at 11:43 AM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> On Mon, 2014-04-28 at 11:37 +0100, David Vrabel wrote:
>> On 28/04/14 11:36, Ian Campbell wrote:
>> > On Mon, 2014-04-28 at 11:24 +0100, David Vrabel wrote:
>> >> On 28/04/14 10:48, Ian Campbell wrote:
>> >>> On Sun, 2014-04-27 at 10:10 +0100, Vladimir Murzin wrote:
>> >>>> Alignment check is enabled by default at Xen boot.
>> >>>
>> >>> This has already been disabled in the development branch via:
>> >>> commit 58bbe7d71239db508c30099bf7b6db7c458f3336
>> >>> Author: Ian Campbell <ian.campbell@xxxxxxxxxx>
>> >>> Date:   Wed Mar 26 13:38:45 2014 +0000
>> >>>
>> >>>     xen: arm64: disable alignment traps
>> >>>
>> >>>     The mem* primitives which I am about to import from Linux in a 
>> >>> subsequent
>> >>>     patch rely on the hardware handling misalignment.
>> >>>
>> >>>     The benefits of an optimised memcpy etc outweigh the downsides.
>> >>>
>> >>>     Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
>> >>>     Acked-by: Julien Grall <julien.grall@xxxxxxxxxx>
>> >>>     Acked-by: Tim Deegan <tim@xxxxxxx>
>> >>>
>> >>> I will consider this for backport, but first I'd like to consider
>> >>> whether we shouldn't fix the hypervisor side evtchn FIFO code along the
>> >>> same lines as the kernel side. David, any thoughts?
>> >>
>> >> I believe Jan suggested making Xen's bitops handle 32-bit alignment or
>> >> adding a new set of 32-bit bitops.
>> >
>> > This is already the case for the arm64 bitops, we deliberately diverged
>> > from Linux here because there are a bunch of other "misaligned" 4-byte
>> > bitmasks (one in the malloc implementation springs to mind).
>>
>> Then I'm not sure what it is you're trying to fix in Xen?
>
> I partially hust wanted to consider whether anything should be better
> changed than rely on the bitops being more flexible, for some reason.
> But I also wanted confirmation that the problematic instruction was
> generated by gcc and not by some handcoded asm somewhere which we hadn't
> properly fixed.
>
> Ian.
>
>

I believe it comes form test_bit (xen/include/asm-arm/bitops.h).

Vladimir

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel