Xen devel - May 2013 - [Xen on Arm BUG] Alignment trap: not handling instruction

Hi,

just a small bug report, not sure if it''s useful. I was just
installing some packages, not doing anything fancy, and I got:

[ 1113.248819] Alignment trap: not handling instruction e8513f00 at
[<b6e88a52>]
[ 1113.254644] Unhandled fault: alignment exception (0x001) at 0x20746e6f

there were no crashes, this just popped up.

Sander

On Thu, 2013-05-02 at 12:46 +0100, Sander Bogaert wrote:
> Hi,
> 
> just a small bug report, not sure if it''s useful. I was just
> installing some packages, not doing anything fancy, and I got:
> 
> [ 1113.248819] Alignment trap: not handling instruction e8513f00 at
[<b6e88a52>]
> [ 1113.254644] Unhandled fault: alignment exception (0x001) at 0x20746e6f
That looks like a kernel message? I assume it was running under Xen.

0xb.... is a userspace address, so some bit of userspace is up to
"something".

I''d have to reread the bits of the ARM and virt extensions to know if
this was our doing ;-)
> 
> there were no crashes, this just popped up.
> 
> Sander
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

On 2 May 2013 15:44, Ian Campbell <Ian.Campbell@citrix.com>
wrote:
> On Thu, 2013-05-02 at 12:46 +0100, Sander Bogaert wrote:
>> Hi,
>>
>> just a small bug report, not sure if it''s useful. I was just
>> installing some packages, not doing anything fancy, and I got:
>>
>> [ 1113.248819] Alignment trap: not handling instruction e8513f00 at
[<b6e88a52>]
>> [ 1113.254644] Unhandled fault: alignment exception (0x001) at
0x20746e6f
>
> That looks like a kernel message? I assume it was running under Xen.
Yes it was.
>
> 0xb.... is a userspace address, so some bit of userspace is up to
> "something".
I''m still learning of course, I missed this. So basically
Xen is mapped on 0x5000000 - ...
Dom0 kernel on 0x8000000 - ...

If an address isn''t in those ( physical ) ranges then it''s
userspace.
Is that correct?
>
> I''d have to reread the bits of the ARM and virt extensions to know
if
> this was our doing ;-)
I was just assuming since it''s a trap but it could indeed be one Xen
isn''t set up to receive. Since I''m using a recent linux kernel
and
wasn''t doing anything funny, just normal usage, I was thinking the
''odd factor'' was Xen underneath. I''ll figure out
which instruction
e8513f00 is.

Thanks for the help.
>
>>
>> there were no crashes, this just popped up.
>>
>> Sander
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>
>

On Thu, 2013-05-02 at 15:34 +0100, Sander Bogaert wrote:
> On 2 May 2013 15:44, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Thu, 2013-05-02 at 12:46 +0100, Sander Bogaert wrote:
> >> Hi,
> >>
> >> just a small bug report, not sure if it''s useful. I was
just
> >> installing some packages, not doing anything fancy, and I got:
> >>
> >> [ 1113.248819] Alignment trap: not handling instruction e8513f00
at [<b6e88a52>]
> >> [ 1113.254644] Unhandled fault: alignment exception (0x001) at
0x20746e6f
> >
> > That looks like a kernel message? I assume it was running under Xen.
> 
> Yes it was.
> 
> >
> > 0xb.... is a userspace address, so some bit of userspace is up to
> > "something".
> 
> I''m still learning of course, I missed this. So basically
> Xen is mapped on 0x5000000 - ...
> Dom0 kernel on 0x8000000 - ...
> 
> If an address isn''t in those ( physical ) ranges then
it''s userspace.
> Is that correct?
Nope ;-)

User vs kernel space is a virtual address distinction. The usual
arrangement for 32-bit Linux (including arm) is a 3:1 split, so 3G of
user and 1G of kernel, meaning kernels a re from 0xc0000000 onwards.

Also remember that physical addresses mean different things to the
hypervisor (physical == real physical) and guests (physical =intermediate
physical address, due to second stage paging).
> > I''d have to reread the bits of the ARM and virt extensions to
know if
> > this was our doing ;-)
> 
> I was just assuming since it''s a trap but it could indeed be one
Xen
> isn''t set up to receive. Since I''m using a recent linux
kernel and
> wasn''t doing anything funny, just normal usage, I was thinking the
> ''odd factor'' was Xen underneath. I''ll figure out
which instruction
> e8513f00 is.
In principal what to do about alignment traps (including whether to
receive them at all) is all the guests decision, that''s not to say Xen
isn''t doing something which causes the kernel to get it wrong.

Ian.