xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
* Basic bare metal ARM domain interface
@ 2016-05-25 19:42 Ivan Pavić2
  2016-05-27 10:04 ` Julien Grall
  0 siblings, 1 reply; 12+ messages in thread
From: Ivan Pavić2 @ 2016-05-25 19:42 UTC (permalink / raw)
  To: xen-devel

Hello,

I'm working on bare metal application for ARM Cortex A7/15 on Odroid XU3 
platform. I'm using Xen 4.6.

After successfully creating bare metal example(by successful I mean I've stuck 
processor in while loop in main function), I probably should initialize memory
management unit and similiar. I've found FreeRTOS project on Github where 
similiar stuff was done for ARM Cortex A15. Project is done for Xen 4.4. 
Xen FreeRTOS project: https://github.com/GaloisInc/FreeRTOS-Xen/ .

1) I'm using 4.6. so I don't know if code from  is fully compatible? (I had to 
comment out lot of things because they block program, printing for example) 

2) Additionally , I would like to implement basic serial output to dom0 from my 
bare metal domU. What is the minimum one should do for implementing console 
output?  

3) Furthermore, as this should be bare metal application, I would like at least 
to be able to toggle LED. How can interface hardware from domU? My first guess
would be to directly address Exynos 5422 GPIO registers but I don't know if
that would work beacause application is running on VCPU (probably not??) ??

Any answer, example of implementation, specific documentation or advice would
be very helpful.

Thank you in advance...

Regards,
Ivan Pavić
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Basic bare metal ARM domain interface
  2016-05-25 19:42 Basic bare metal ARM domain interface Ivan Pavić2
@ 2016-05-27 10:04 ` Julien Grall
  2016-05-27 13:19   ` Ivan Pavić2
       [not found]   ` <20160527211650.GA43457@galois.com>
  0 siblings, 2 replies; 12+ messages in thread
From: Julien Grall @ 2016-05-27 10:04 UTC (permalink / raw)
  To: Ivan Pavić2, xen-devel; +Cc: jtd



On 25/05/16 20:42, Ivan Pavić2 wrote:
> Hello,

Hello Ivan,

> I'm working on bare metal application for ARM Cortex A7/15 on Odroid XU3
> platform. I'm using Xen 4.6.
>
> After successfully creating bare metal example(by successful I mean I've stuck
> processor in while loop in main function), I probably should initialize memory
> management unit and similiar. I've found FreeRTOS project on Github where
> similiar stuff was done for ARM Cortex A15. Project is done for Xen 4.4.
> Xen FreeRTOS project: https://github.com/GaloisInc/FreeRTOS-Xen/ .
>
> 1) I'm using 4.6. so I don't know if code from  is fully compatible? (I had to
> comment out lot of things because they block program, printing for example)

If I remember correctly, FreeRTOS is not using the device-tree to find 
where reside the GIC MMIO regions (and possible other MMIOs).

The memory layout has been reworked between Xen 4.4 and Xen 4.5. So you 
will need to update the base address hardcoded in FreeRTOS.

I have CCed, Jonathan who did the FreeRTOS port for Xen. He will be able 
to give you more details about it.

>
> 2) Additionally , I would like to implement basic serial output to dom0 from my
> bare metal domU. What is the minimum one should do for implementing console
> output?

We provide a PV console interface. The backend is already implement in 
dom0 (assuming you are using Linux). For the frontend, you can give a 
look, how mini-os [1] has implemented it.

>
> 3) Furthermore, as this should be bare metal application, I would like at least
> to be able to toggle LED. How can interface hardware from domU? My first guess
> would be to directly address Exynos 5422 GPIO registers but I don't know if
> that would work beacause application is running on VCPU (probably not??) ??

By default, the guest has no access to the hardware. You will need to 
specify in the configure file the list of MMIO regions the guest is 
allowed to access. You can find more details about it here [2].

>
> Any answer, example of implementation, specific documentation or advice would
> be very helpful.

There were a few talks to explain how to port an OS on XEN:
  - 
https://events.linuxfoundation.org/sites/events/files/slides/FreeRTOSXenSummit_0.pdf
  - http://fr.slideshare.net/xen_com_mgr/bsdcan-2015-how-to-port-your-bsd

I hope this will help you to create your bare metal app. Feel free to 
send an e-email if you have more questions.

Regards,

[1] 
http://xenbits.xen.org/gitweb/?p=mini-os.git;a=tree;f=console;h=61f51490a1aefc15148b6e1f016d9e63bbfe61aa;hb=HEAD
[2] https://events.linuxfoundation.org/sites/events/files/slides/talk_5.pdf

-- 
Julien Grall

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Basic bare metal ARM domain interface
  2016-05-27 10:04 ` Julien Grall
@ 2016-05-27 13:19   ` Ivan Pavić2
       [not found]   ` <20160527211650.GA43457@galois.com>
  1 sibling, 0 replies; 12+ messages in thread
From: Ivan Pavić2 @ 2016-05-27 13:19 UTC (permalink / raw)
  To: Julien Grall, xen-devel; +Cc: jtd

Hello, 

Jullien, thanks for docs and references. 

I used FreeRTOS code for console output. It is based on Mini OS code. There are two problems as I've determined with debugging. First is that vsnprintf blocks for some reason in print function so i commented it out. After the hypercall function blocked as well. I modified hypercall function so it looks like this:

(void)HYPERVISOR_console_io(CONSOLEIO_write, 3, "yes");

hoping to get "yes" as output..., but this blocked as well.

xenctx output after HYPERVISOR_console_io:

PC:       4000828c
CPSR:     200001d7
USR:               SP:00000000 LR:00000000
SVC: SPSR:00000000 SP:4011bff4 LR:4000a37f
FIQ: SPSR:00000000 SP:40124200 LR:00000000
IRQ: SPSR:00000000 SP:40120200 LR:00000000
ABT: SPSR:200001f7 SP:40008140 LR:3f741306
UND: SPSR:00000000 SP:4012c200 LR:00000000

 r0_usr: 4000815f        r1_usr: 00000000        r2_usr: 40008160
 r3_usr: 4000815c        r4_usr: ffffa338        r5_usr: 4000c948
 r6_usr: 00000000        r7_usr: 4000a53c        r8_usr: 00000000
 r9_usr: 00000000       r10_usr: 00000065       r11_usr: 00000000
r12_usr: 00000000

 r8_fiq: 00000000
 r9_fiq: 00000000       r10_fiq: 00000000       r11_fiq: 00000000
r12_fiq: 00000000

SCTLR: 00c50078
TTBCR: 0000000000000000
TTBR0: 0000000000000000
TTBR1: 0000000000000000

r10 = 101, I used it for debugging, to locate code where it is stuck. What could it be?

Thanks in advance,

Ivan Pavic.


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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Basic bare metal ARM domain interface
       [not found]   ` <20160527211650.GA43457@galois.com>
@ 2016-05-28 11:21     ` Ivan Pavić2
  2016-05-30 20:21       ` Odgovor: " Ivan Pavić2
  0 siblings, 1 reply; 12+ messages in thread
From: Ivan Pavić2 @ 2016-05-28 11:21 UTC (permalink / raw)
  To: Jonathan Daugherty, Julien Grall, xen-devel; +Cc: Adam Wick

Hello, 

> I used FreeRTOS code for console output. It is based on Mini OS code. There are two problems as I've determined
> with debugging. First is that vsnprintf blocks for some reason in print function so i commented it out. After the 

snprintf blocks...

> hypercall function blocked as well. I modified hypercall function so it looks like this:
> (void)HYPERVISOR_console_io(CONSOLEIO_write, 3, "yes");

As the call failed I decided to make hypervisor call directly in boot procedure, so I put this assembler code just before
branch to main: 

        mov r12, #18 ; console io code
        mov r0, #0 ; write operation(first parameter)
        mov r1, #5 ; length of message (second parameter)
        ldr r2, =msg ; message address (third parameter)
        .long 0xe140ea71 ; hvc instruction
        b main ; branch to main

msg is defined as:

msg:
    .asciz "hello"

I get deadbeef in registers, apperently something happened (xenctx output):
PC:       4000c5bc
CPSR:     600001f3
USR:               SP:00000000 LR:00000000
SVC: SPSR:00000000 SP:4011c200 LR:400080a8
FIQ: SPSR:00000000 SP:40124200 LR:00000000
IRQ: SPSR:00000000 SP:40120200 LR:00000000
ABT: SPSR:00000000 SP:40128200 LR:00000000
UND: SPSR:00000000 SP:4012c200 LR:00000000

 r0_usr: 00000000        r1_usr: deadbeef        r2_usr: deadbeef
 r3_usr: 00000000        r4_usr: 00000000        r5_usr: 00000000
 r6_usr: 00000000        r7_usr: 00000000        r8_usr: 00000000
 r9_usr: 00000064       r10_usr: 00000064       r11_usr: 00000000
r12_usr: deadbeef


According to arch-arm.h r0 is return value of call. It is 0, operation successful???? Still I don't get output on 
console...

Thank you in advance,

Regards,

Ivan Pavic 



 




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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Odgovor:  Basic bare metal ARM domain interface
  2016-05-28 11:21     ` Ivan Pavić2
@ 2016-05-30 20:21       ` Ivan Pavić2
  2016-05-31  9:53         ` Julien Grall
  0 siblings, 1 reply; 12+ messages in thread
From: Ivan Pavić2 @ 2016-05-30 20:21 UTC (permalink / raw)
  To: Jonathan Daugherty, Julien Grall, xen-devel; +Cc: Adam Wick

Hello, 

>> I used FreeRTOS code for console output. It is based on Mini OS code. There are two problems as I've >determined
>> with debugging. First is that vsnprintf blocks for some reason in print function so i commented it out. After the

>snprintf blocks...

>> hypercall function blocked as well. I modified hypercall function so it looks like this:
>>(void)HYPERVISOR_console_io(CONSOLEIO_write, 3, "yes");

>As the call failed I decided to make hypervisor call directly in boot procedure, so I put this assembler code just >before
>branch to main:

>        mov r12, #18 ; console io code
>        mov r0, #0 ; write operation(first parameter)
>        mov r1, #5 ; length of message (second parameter)
>       ldr r2, =msg ; message address (third parameter)
>        .long 0xe140ea71 ; hvc instruction
>        b main ; branch to main

>msg is defined as:

>msg:
>    .asciz "hello"

>I get deadbeef in registers, apperently something happened (xenctx output):
>PC:       4000c5bc
>CPSR:     600001f3
>USR:               SP:00000000 LR:00000000
>SVC: SPSR:00000000 SP:4011c200 LR:400080a8
>FIQ: SPSR:00000000 SP:40124200 LR:00000000
>IRQ: SPSR:00000000 SP:40120200 LR:00000000
>ABT: SPSR:00000000 SP:40128200 LR:00000000
>UND: SPSR:00000000 SP:4012c200 LR:00000000

 >r0_usr: 00000000        r1_usr: deadbeef        r2_usr: deadbeef
 >r3_usr: 00000000        r4_usr: 00000000        r5_usr: 00000000
 >r6_usr: 00000000        r7_usr: 00000000        r8_usr: 00000000
 >r9_usr: 00000064       r10_usr: 00000064       r11_usr: 00000000
>r12_usr: deadbeef


>According to arch-arm.h r0 is return value of call. It is 0, operation successful???? Still I don't get output on
>console...

>Thank you in advance,

>Regards,

>Ivan Pavic

I still didn't solve why I don't see no output on emergency console, I think I should because if deadbeef in registers it 
do_console_io should have been called. However new problem emerged i tried to add iomem 
parameter in configuration file to get access over gpio but domain won't start because operation is not permitted. 
Should I somehow release disable that memory space for dom0, perhaps in dts for dom0? 

Snippet from dom.cfg file:

iomem = ["0x13400000,1@0x41400000"]

0x13400000 is base address of GPIO that I want to use.

I get this error: (snippet from xl -vvv create -c dom.cfg)

libxl: debug: libxl_create.c:1213:domcreate_launch_dm: dom4 iomem 13400000-13400000
libxl: error: libxl_create.c:1220:domcreate_launch_dm: failed give dom4 access to iomem range 13400000-13400000: Operation not permitted
libxl: debug: libxl.c:1719:devices_destroy_cb: forked pid 3835 for destroy of domain 4

Thank you in advance,

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

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Odgovor:  Basic bare metal ARM domain interface
  2016-05-30 20:21       ` Odgovor: " Ivan Pavić2
@ 2016-05-31  9:53         ` Julien Grall
  2016-06-01 20:06           ` Ivan Pavic
  0 siblings, 1 reply; 12+ messages in thread
From: Julien Grall @ 2016-05-31  9:53 UTC (permalink / raw)
  To: Ivan Pavić2, Jonathan Daugherty, xen-devel
  Cc: Adam Wick, Stefano Stabellini



On 30/05/16 21:21, Ivan Pavić2 wrote:
> Hello,

Hello Ivan,

Sorry for the late answer.

>>> I used FreeRTOS code for console output. It is based on Mini OS code. There are two problems as I've >determined
>>> with debugging. First is that vsnprintf blocks for some reason in print function so i commented it out. After the
>
>> snprintf blocks...
>
>>> hypercall function blocked as well. I modified hypercall function so it looks like this:
>>> (void)HYPERVISOR_console_io(CONSOLEIO_write, 3, "yes");
>
>> As the call failed I decided to make hypervisor call directly in boot procedure, so I put this assembler code just >before
>> branch to main:
>
>>         mov r12, #18 ; console io code
>>         mov r0, #0 ; write operation(first parameter)
>>         mov r1, #5 ; length of message (second parameter)
>>        ldr r2, =msg ; message address (third parameter)
>>         .long 0xe140ea71 ; hvc instruction
>>         b main ; branch to main

For your information, hypervisor calls have to be done with data cache 
enabled. Otherwise you not may get garbage (or nothing at all) on the 
console.

>
>> msg is defined as:
>
>> msg:
>>     .asciz "hello"
>
>> I get deadbeef in registers, apperently something happened (xenctx output):
>> PC:       4000c5bc
>> CPSR:     600001f3
>> USR:               SP:00000000 LR:00000000
>> SVC: SPSR:00000000 SP:4011c200 LR:400080a8
>> FIQ: SPSR:00000000 SP:40124200 LR:00000000
>> IRQ: SPSR:00000000 SP:40120200 LR:00000000
>> ABT: SPSR:00000000 SP:40128200 LR:00000000
>> UND: SPSR:00000000 SP:4012c200 LR:00000000
>
>   >r0_usr: 00000000        r1_usr: deadbeef        r2_usr: deadbeef
>   >r3_usr: 00000000        r4_usr: 00000000        r5_usr: 00000000
>   >r6_usr: 00000000        r7_usr: 00000000        r8_usr: 00000000
>   >r9_usr: 00000064       r10_usr: 00000064       r11_usr: 00000000
>> r12_usr: deadbeef
>
>
>> According to arch-arm.h r0 is return value of call. It is 0, operation successful???? Still I don't get output on
>> console...
>
>> Thank you in advance,
>
>> Regards,
>
>> Ivan Pavic
>
> I still didn't solve why I don't see no output on emergency console, I think I should because if deadbeef in registers it
> do_console_io should have been called.

The emergency console and any Xen debug facilities (hvc 0xffxx) only 
works when the hypervisor has been built with debug enabled.

By default, release version are built with debug disabled. You will have 
to pass debug=y on the build command line to enable debug.

> However new problem emerged i tried to add iomem
> parameter in configuration file to get access over gpio but domain won't start because operation is not permitted.
> Should I somehow release disable that memory space for dom0, perhaps in dts for dom0?
>
> Snippet from dom.cfg file:
>
> iomem = ["0x13400000,1@0x41400000"]
>
> 0x13400000 is base address of GPIO that I want to use.

iomem expects a physical page number (see the documentation in 
docs/man/xl.cfg.pod.5). So it should be:

iomem = ["0x13400,1@0x41400"]

>
> I get this error: (snippet from xl -vvv create -c dom.cfg)
>
> libxl: debug: libxl_create.c:1213:domcreate_launch_dm: dom4 iomem 13400000-13400000
> libxl: error: libxl_create.c:1220:domcreate_launch_dm: failed give dom4 access to iomem range 13400000-13400000: Operation not permitted
> libxl: debug: libxl.c:1719:devices_destroy_cb: forked pid 3835 for destroy of domain 4
>
> Thank you in advance,

Regards,

-- 
Julien Grall

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Basic bare metal ARM domain interface
  2016-05-31  9:53         ` Julien Grall
@ 2016-06-01 20:06           ` Ivan Pavic
  2016-06-02 11:41             ` Julien Grall
  0 siblings, 1 reply; 12+ messages in thread
From: Ivan Pavic @ 2016-06-01 20:06 UTC (permalink / raw)
  To: Julien Grall; +Cc: xen-devel, Jonathan Daugherty, Adam Wick, Stefano Stabellini

On Tue, May 31, 2016 at 10:53:06AM +0100, Julien Grall wrote:
> 
> 
> On 30/05/16 21:21, Ivan Pavić2 wrote:
> >Hello,
> 
> Hello Ivan,
> 
> Sorry for the late answer.
> 
> >>>I used FreeRTOS code for console output. It is based on Mini OS code. There are two problems as I've >determined
> >>>with debugging. First is that vsnprintf blocks for some reason in print function so i commented it out. After the
> >
> >>snprintf blocks...
> >
> >>>hypercall function blocked as well. I modified hypercall function so it looks like this:
> >>>(void)HYPERVISOR_console_io(CONSOLEIO_write, 3, "yes");
> >
> >>As the call failed I decided to make hypervisor call directly in boot procedure, so I put this assembler code just >before
> >>branch to main:
> >
> >>        mov r12, #18 ; console io code
> >>        mov r0, #0 ; write operation(first parameter)
> >>        mov r1, #5 ; length of message (second parameter)
> >>       ldr r2, =msg ; message address (third parameter)
> >>        .long 0xe140ea71 ; hvc instruction
> >>        b main ; branch to main
> 
> For your information, hypervisor calls have to be done with data
> cache enabled. Otherwise you not may get garbage (or nothing at all)
> on the console.
> 
> >
> >>msg is defined as:
> >
> >>msg:
> >>    .asciz "hello"
> >
> >>I get deadbeef in registers, apperently something happened (xenctx output):
> >>PC:       4000c5bc
> >>CPSR:     600001f3
> >>USR:               SP:00000000 LR:00000000
> >>SVC: SPSR:00000000 SP:4011c200 LR:400080a8
> >>FIQ: SPSR:00000000 SP:40124200 LR:00000000
> >>IRQ: SPSR:00000000 SP:40120200 LR:00000000
> >>ABT: SPSR:00000000 SP:40128200 LR:00000000
> >>UND: SPSR:00000000 SP:4012c200 LR:00000000
> >
> >  >r0_usr: 00000000        r1_usr: deadbeef        r2_usr: deadbeef
> >  >r3_usr: 00000000        r4_usr: 00000000        r5_usr: 00000000
> >  >r6_usr: 00000000        r7_usr: 00000000        r8_usr: 00000000
> >  >r9_usr: 00000064       r10_usr: 00000064       r11_usr: 00000000
> >>r12_usr: deadbeef
> >
> >
> >>According to arch-arm.h r0 is return value of call. It is 0, operation successful???? Still I don't get output on
> >>console...
> >
> >>Thank you in advance,
> >
> >>Regards,
> >
> >>Ivan Pavic
> >
> >I still didn't solve why I don't see no output on emergency console, I think I should because if deadbeef in registers it
> >do_console_io should have been called.
> 
> The emergency console and any Xen debug facilities (hvc 0xffxx) only
> works when the hypervisor has been built with debug enabled.
> 
> By default, release version are built with debug disabled. You will
> have to pass debug=y on the build command line to enable debug.
> 
> >However new problem emerged i tried to add iomem
> >parameter in configuration file to get access over gpio but domain won't start because operation is not permitted.
> >Should I somehow release disable that memory space for dom0, perhaps in dts for dom0?
> >
> >Snippet from dom.cfg file:
> >
> >iomem = ["0x13400000,1@0x41400000"]
> >
> >0x13400000 is base address of GPIO that I want to use.
> 
> iomem expects a physical page number (see the documentation in
> docs/man/xl.cfg.pod.5). So it should be:
> 
> iomem = ["0x13400,1@0x41400"]
> 
> >
> >I get this error: (snippet from xl -vvv create -c dom.cfg)
> >
> >libxl: debug: libxl_create.c:1213:domcreate_launch_dm: dom4 iomem 13400000-13400000
> >libxl: error: libxl_create.c:1220:domcreate_launch_dm: failed give dom4 access to iomem range 13400000-13400000: Operation not permitted
> >libxl: debug: libxl.c:1719:devices_destroy_cb: forked pid 3835 for destroy of domain 4
> >
> >Thank you in advance,
> 
> Regards,
> 
> -- 
> Julien Grall

Hello Julien,

thank you very much, I succeded with debug console and pin toggle (iomem).
It's actually good that you answered late, because it made me look through xen
traps.c and console.c code, so I recompiled xen few times. The main problem with
was compiler, I think. I've always got data abort with hypervisor calls and 
similiar. Now I'm using gcc-linaro-arm-none-eabi-4.9 for both xen and 
application. I'll try to document this as much as possible and I'll put code 
on github. (github.com/dumpram). Next thing I will do, is to measure gpio 
latency in dom0 and guest domain with different schedulers. Final step would 
be to create starting point for porting some RTOS. Thank you once again for the 
patience, with my beginner questions, but I'm afraid that there will be more...

Regards,

Ivan Pavic
 




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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Basic bare metal ARM domain interface
  2016-06-01 20:06           ` Ivan Pavic
@ 2016-06-02 11:41             ` Julien Grall
  2016-06-02 19:09               ` Ivan Pavic
  0 siblings, 1 reply; 12+ messages in thread
From: Julien Grall @ 2016-06-02 11:41 UTC (permalink / raw)
  To: Ivan Pavic; +Cc: xen-devel, Jonathan Daugherty, Adam Wick, Stefano Stabellini



On 01/06/16 21:06, Ivan Pavic wrote:
> On Tue, May 31, 2016 at 10:53:06AM +0100, Julien Grall wrote:
> Hello Julien,

Hello Ivan,

> thank you very much, I succeded with debug console and pin toggle (iomem).
> It's actually good that you answered late, because it made me look through xen
> traps.c and console.c code, so I recompiled xen few times. The main problem with
> was compiler, I think. I've always got data abort with hypervisor calls and
> similiar. Now I'm using gcc-linaro-arm-none-eabi-4.9 for both xen and
> application.

Your guest (i.e the application) and Xen should not need to be built 
with the same compiler.

Which compiler led to use a data abort? And where was the data abort? In 
Xen or the guest?

Regards,

-- 
Julien Grall

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Basic bare metal ARM domain interface
  2016-06-02 11:41             ` Julien Grall
@ 2016-06-02 19:09               ` Ivan Pavic
  2016-06-03 10:23                 ` Julien Grall
  0 siblings, 1 reply; 12+ messages in thread
From: Ivan Pavic @ 2016-06-02 19:09 UTC (permalink / raw)
  To: Julien Grall; +Cc: xen-devel, Jonathan Daugherty, Adam Wick, Stefano Stabellini

Hello Julien,

On Thu, Jun 02, 2016 at 12:41:02PM +0100, Julien Grall wrote:
> 
> Which compiler led to use a data abort? And where was the data
> abort? In Xen or the guest?
>

When I compile app directly on ODROID I used:
arm-linux-gnueabihf
gcc version 4.8.4 (Ubuntu/Linaro 4.8.4-2ubuntu1~14.04.1) 

HVC instruction works form assembler, but when I call it from main, for
example: 
HYPERVISOR_console_io (HYPERCALL_WRITE, SYSTEM_UP_LEN, SYSTEM_UP_MSG);
then I get this in xl dmesg:
traps.c:2450:d2v0 HSR=0x90000046 pc=0x40008250 gva=0 gpa=0000000000000000

This doesn't happen with other compiler. 

Regards, 

Ivan Pavic

 


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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Basic bare metal ARM domain interface
  2016-06-02 19:09               ` Ivan Pavic
@ 2016-06-03 10:23                 ` Julien Grall
  2016-06-06 23:31                   ` Ivan Pavic
  0 siblings, 1 reply; 12+ messages in thread
From: Julien Grall @ 2016-06-03 10:23 UTC (permalink / raw)
  To: Ivan Pavic; +Cc: xen-devel, Jonathan Daugherty, Adam Wick, Stefano Stabellini



On 02/06/16 20:09, Ivan Pavic wrote:
> Hello Julien,

Hello Ivan,

> On Thu, Jun 02, 2016 at 12:41:02PM +0100, Julien Grall wrote:
>>
>> Which compiler led to use a data abort? And where was the data
>> abort? In Xen or the guest?
>>
>
> When I compile app directly on ODROID I used:
> arm-linux-gnueabihf
> gcc version 4.8.4 (Ubuntu/Linaro 4.8.4-2ubuntu1~14.04.1)
>
> HVC instruction works form assembler, but when I call it from main, for
> example:
> HYPERVISOR_console_io (HYPERCALL_WRITE, SYSTEM_UP_LEN, SYSTEM_UP_MSG);
> then I get this in xl dmesg:
> traps.c:2450:d2v0 HSR=0x90000046 pc=0x40008250 gva=0 gpa=0000000000000000

To be honest this looks like a latent issue in your app rather than a 
bug in the compiler.

I would try to find which instruction is causing the data abort. Also is 
your app running with page table and cache enabled?

Regards,

-- 
Julien Grall

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Basic bare metal ARM domain interface
  2016-06-03 10:23                 ` Julien Grall
@ 2016-06-06 23:31                   ` Ivan Pavic
  2016-06-07 14:18                     ` Julien Grall
  0 siblings, 1 reply; 12+ messages in thread
From: Ivan Pavic @ 2016-06-06 23:31 UTC (permalink / raw)
  To: Julien Grall; +Cc: xen-devel, Jonathan Daugherty, Adam Wick, Stefano Stabellini

Hello Julien,

On Fri, Jun 03, 2016 at 11:23:33AM +0100, Julien Grall wrote:
> 
> 
> On 02/06/16 20:09, Ivan Pavic wrote:
> >Hello Julien,
> 
> Hello Ivan,
> 
> >On Thu, Jun 02, 2016 at 12:41:02PM +0100, Julien Grall wrote:
> >>
> >>Which compiler led to use a data abort? And where was the data
> >>abort? In Xen or the guest?
> >>
> >
> >When I compile app directly on ODROID I used:
> >arm-linux-gnueabihf
> >gcc version 4.8.4 (Ubuntu/Linaro 4.8.4-2ubuntu1~14.04.1)
> >
> >HVC instruction works form assembler, but when I call it from main, for
> >example:
> >HYPERVISOR_console_io (HYPERCALL_WRITE, SYSTEM_UP_LEN, SYSTEM_UP_MSG);
> >then I get this in xl dmesg:
> >traps.c:2450:d2v0 HSR=0x90000046 pc=0x40008250 gva=0 gpa=0000000000000000
> 
> To be honest this looks like a latent issue in your app rather than
> a bug in the compiler.
> 
> I would try to find which instruction is causing the data abort.
> Also is your app running with page table and cache enabled?
> 

Page table and cache are related to MMU, right? I didn't initialize MMU 
so far.

Regards,

Ivan Pavic



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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Basic bare metal ARM domain interface
  2016-06-06 23:31                   ` Ivan Pavic
@ 2016-06-07 14:18                     ` Julien Grall
  0 siblings, 0 replies; 12+ messages in thread
From: Julien Grall @ 2016-06-07 14:18 UTC (permalink / raw)
  To: Ivan Pavic; +Cc: xen-devel, Jonathan Daugherty, Adam Wick, Stefano Stabellini



On 07/06/16 00:31, Ivan Pavic wrote:
> Hello Julien,

Hello Ivan,

> On Fri, Jun 03, 2016 at 11:23:33AM +0100, Julien Grall wrote:
>>
>>
>> On 02/06/16 20:09, Ivan Pavic wrote:
>>> Hello Julien,
>>
>> Hello Ivan,
>>
>>> On Thu, Jun 02, 2016 at 12:41:02PM +0100, Julien Grall wrote:
>>>>
>>>> Which compiler led to use a data abort? And where was the data
>>>> abort? In Xen or the guest?
>>>>
>>>
>>> When I compile app directly on ODROID I used:
>>> arm-linux-gnueabihf
>>> gcc version 4.8.4 (Ubuntu/Linaro 4.8.4-2ubuntu1~14.04.1)
>>>
>>> HVC instruction works form assembler, but when I call it from main, for
>>> example:
>>> HYPERVISOR_console_io (HYPERCALL_WRITE, SYSTEM_UP_LEN, SYSTEM_UP_MSG);
>>> then I get this in xl dmesg:
>>> traps.c:2450:d2v0 HSR=0x90000046 pc=0x40008250 gva=0 gpa=0000000000000000
>>
>> To be honest this looks like a latent issue in your app rather than
>> a bug in the compiler.
>>
>> I would try to find which instruction is causing the data abort.
>> Also is your app running with page table and cache enabled?
>>
>
> Page table and cache are related to MMU, right? I didn't initialize MMU
> so far.

All the memory buffer passed to the hypercall should be cacheable (see 
xen/include/public/asm-arm.h for more details). I.e the MMU should be 
enabled.

Otherwise, the behavior is unreliable because the memory attribute will 
be different in Xen and the guest. Xen is mapping the region cacheable.

Regards,

-- 
Julien Grall

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2016-06-07 14:18 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-05-25 19:42 Basic bare metal ARM domain interface Ivan Pavić2
2016-05-27 10:04 ` Julien Grall
2016-05-27 13:19   ` Ivan Pavić2
     [not found]   ` <20160527211650.GA43457@galois.com>
2016-05-28 11:21     ` Ivan Pavić2
2016-05-30 20:21       ` Odgovor: " Ivan Pavić2
2016-05-31  9:53         ` Julien Grall
2016-06-01 20:06           ` Ivan Pavic
2016-06-02 11:41             ` Julien Grall
2016-06-02 19:09               ` Ivan Pavic
2016-06-03 10:23                 ` Julien Grall
2016-06-06 23:31                   ` Ivan Pavic
2016-06-07 14:18                     ` Julien Grall

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).