Xen GCC coverage ARM64 testing - Unexpected Trap: Data Abort

Xen GCC coverage ARM64 testing - Unexpected Trap: Data Abort

[Viktor Mitin]

[-- Attachment #1: Type: text/plain, Size: 1163 bytes --]

Hi All,

Please be aware that we have tried Xen ARM64 build with
CONFIG_COVERAGE feature enabled. The build environment is next:
Xen Versions tested: xen-4.12-stable, xen-4.13-staging
Board: H3ULCB, R-Car H3 Ver.2.0
Poky: Yocto Project Reference Distro 2.4.2
Compiler: aarch64-poky-linux-gcc (Linaro GCC 7.2-2017.11) 7.2.1

Both Xen versions (4.12 and staging) return "Unexpected Trap: Data
Abort" issue in case of 'xencov reset' or 'xencov read' calls:

root@h3ulcb:~# xencov reset
(XEN) Data Abort Trap. Syndrome=0x7
(XEN) Walking Hypervisor VA 0x361700 on CPU3 via TTBR 0x0000000078266000
(XEN) 0TH[0x0] = 0x0000000078265f7f
(XEN) 1ST[0x0] = 0x0000000078262f7f
(XEN) 2ND[0x1] = 0x004000007825ff7f
(XEN) 3RD[0x161] = 0x00600000781e1f7e
(XEN) CPU3: Unexpected Trap: Data Abort

Attaching the next log files (zipped in
xen_with_config_coverage_logs.zip) with the details:
- all the run-time exception details (rcarh3_config_coverage_trap.log);
- xen package build log file with compilation options (compilation.log);
- xen hypervisor .config file used for the build (xen_dot_config.log);

Please share any comments or ideas about the issue.

Thanks,
Viktor Mitin

[-- Attachment #2: xen_with_config_coverage_logs.zip --]
[-- Type: application/zip, Size: 55348 bytes --]

[-- Attachment #3: Type: text/plain, Size: 157 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] Xen GCC coverage ARM64 testing - Unexpected Trap: Data Abort

[Viktor Mitin]

[-- Attachment #1: Type: text/plain, Size: 1163 bytes --]

Hi All,

Please be aware that we have tried Xen ARM64 build with
CONFIG_COVERAGE feature enabled. The build environment is next:
Xen Versions tested: xen-4.12-stable, xen-4.13-staging
Board: H3ULCB, R-Car H3 Ver.2.0
Poky: Yocto Project Reference Distro 2.4.2
Compiler: aarch64-poky-linux-gcc (Linaro GCC 7.2-2017.11) 7.2.1

Both Xen versions (4.12 and staging) return "Unexpected Trap: Data
Abort" issue in case of 'xencov reset' or 'xencov read' calls:

root@h3ulcb:~# xencov reset
(XEN) Data Abort Trap. Syndrome=0x7
(XEN) Walking Hypervisor VA 0x361700 on CPU3 via TTBR 0x0000000078266000
(XEN) 0TH[0x0] = 0x0000000078265f7f
(XEN) 1ST[0x0] = 0x0000000078262f7f
(XEN) 2ND[0x1] = 0x004000007825ff7f
(XEN) 3RD[0x161] = 0x00600000781e1f7e
(XEN) CPU3: Unexpected Trap: Data Abort

Attaching the next log files (zipped in
xen_with_config_coverage_logs.zip) with the details:
- all the run-time exception details (rcarh3_config_coverage_trap.log);
- xen package build log file with compilation options (compilation.log);
- xen hypervisor .config file used for the build (xen_dot_config.log);

Please share any comments or ideas about the issue.

Thanks,
Viktor Mitin

[-- Attachment #2: xen_with_config_coverage_logs.zip --]
[-- Type: application/zip, Size: 55348 bytes --]

[-- Attachment #3: Type: text/plain, Size: 157 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: Xen GCC coverage ARM64 testing - Unexpected Trap: Data Abort

[Viktor Mitin]

Adding Xen maintainers to this email CC.

Thanks

On Thu, May 2, 2019 at 5:08 PM Viktor Mitin <viktor.mitin.19@gmail.com> wrote:
>
> Hi All,
>
> Please be aware that we have tried Xen ARM64 build with
> CONFIG_COVERAGE feature enabled. The build environment is next:
> Xen Versions tested: xen-4.12-stable, xen-4.13-staging
> Board: H3ULCB, R-Car H3 Ver.2.0
> Poky: Yocto Project Reference Distro 2.4.2
> Compiler: aarch64-poky-linux-gcc (Linaro GCC 7.2-2017.11) 7.2.1
>
> Both Xen versions (4.12 and staging) return "Unexpected Trap: Data
> Abort" issue in case of 'xencov reset' or 'xencov read' calls:
>
> root@h3ulcb:~# xencov reset
> (XEN) Data Abort Trap. Syndrome=0x7
> (XEN) Walking Hypervisor VA 0x361700 on CPU3 via TTBR 0x0000000078266000
> (XEN) 0TH[0x0] = 0x0000000078265f7f
> (XEN) 1ST[0x0] = 0x0000000078262f7f
> (XEN) 2ND[0x1] = 0x004000007825ff7f
> (XEN) 3RD[0x161] = 0x00600000781e1f7e
> (XEN) CPU3: Unexpected Trap: Data Abort
>
> Attaching the next log files (zipped in
> xen_with_config_coverage_logs.zip) with the details:
> - all the run-time exception details (rcarh3_config_coverage_trap.log);
> - xen package build log file with compilation options (compilation.log);
> - xen hypervisor .config file used for the build (xen_dot_config.log);
>
> Please share any comments or ideas about the issue.
>
> Thanks,
> Viktor Mitin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Xen GCC coverage ARM64 testing - Unexpected Trap: Data Abort

[Viktor Mitin]

Adding Xen maintainers to this email CC.

Thanks

On Thu, May 2, 2019 at 5:08 PM Viktor Mitin <viktor.mitin.19@gmail.com> wrote:
>
> Hi All,
>
> Please be aware that we have tried Xen ARM64 build with
> CONFIG_COVERAGE feature enabled. The build environment is next:
> Xen Versions tested: xen-4.12-stable, xen-4.13-staging
> Board: H3ULCB, R-Car H3 Ver.2.0
> Poky: Yocto Project Reference Distro 2.4.2
> Compiler: aarch64-poky-linux-gcc (Linaro GCC 7.2-2017.11) 7.2.1
>
> Both Xen versions (4.12 and staging) return "Unexpected Trap: Data
> Abort" issue in case of 'xencov reset' or 'xencov read' calls:
>
> root@h3ulcb:~# xencov reset
> (XEN) Data Abort Trap. Syndrome=0x7
> (XEN) Walking Hypervisor VA 0x361700 on CPU3 via TTBR 0x0000000078266000
> (XEN) 0TH[0x0] = 0x0000000078265f7f
> (XEN) 1ST[0x0] = 0x0000000078262f7f
> (XEN) 2ND[0x1] = 0x004000007825ff7f
> (XEN) 3RD[0x161] = 0x00600000781e1f7e
> (XEN) CPU3: Unexpected Trap: Data Abort
>
> Attaching the next log files (zipped in
> xen_with_config_coverage_logs.zip) with the details:
> - all the run-time exception details (rcarh3_config_coverage_trap.log);
> - xen package build log file with compilation options (compilation.log);
> - xen hypervisor .config file used for the build (xen_dot_config.log);
>
> Please share any comments or ideas about the issue.
>
> Thanks,
> Viktor Mitin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: Xen GCC coverage ARM64 testing - Unexpected Trap: Data Abort

[Julien Grall]

Hi,

On 5/2/19 3:50 PM, Viktor Mitin wrote:
> Adding Xen maintainers to this email CC.
> 
> Thanks
> 
> On Thu, May 2, 2019 at 5:08 PM Viktor Mitin <viktor.mitin.19@gmail.com> wrote:
>>
>> Hi All,
>>
>> Please be aware that we have tried Xen ARM64 build with
>> CONFIG_COVERAGE feature enabled. The build environment is next:
>> Xen Versions tested: xen-4.12-stable, xen-4.13-staging
>> Board: H3ULCB, R-Car H3 Ver.2.0
>> Poky: Yocto Project Reference Distro 2.4.2
>> Compiler: aarch64-poky-linux-gcc (Linaro GCC 7.2-2017.11) 7.2.1
>>
>> Both Xen versions (4.12 and staging) return "Unexpected Trap: Data
>> Abort" issue in case of 'xencov reset' or 'xencov read' calls:
>>
>> root@h3ulcb:~# xencov reset
>> (XEN) Data Abort Trap. Syndrome=0x7

Per the value, the syndrome is invalid. As I will not open a zip (see 
below why), could you post the full stack trace?

>> (XEN) Walking Hypervisor VA 0x361700 on CPU3 via TTBR 0x0000000078266000
>> (XEN) 0TH[0x0] = 0x0000000078265f7f
>> (XEN) 1ST[0x0] = 0x0000000078262f7f
>> (XEN) 2ND[0x1] = 0x004000007825ff7f
>> (XEN) 3RD[0x161] = 0x00600000781e1f7e
>> (XEN) CPU3: Unexpected Trap: Data Abort
>>
>> Attaching the next log files (zipped in
>> xen_with_config_coverage_logs.zip) with the details:

Please don't send a 54KB attachment on the mailing list. This is using 
up space for every one on the ML. Instead you should upload somewhere 
(e.g pastebin).

But I am afraid, I am not going to open any archive sent on the mailing 
list. Please upload file separately. However....

>> - all the run-time exception details (rcarh3_config_coverage_trap.log);
>> - xen package build log file with compilation options (compilation.log);

This is not necessary.

>> - xen hypervisor .config file used for the build (xen_dot_config.log);
>>
>> Please share any comments or ideas about the issue.

GCOV on Arm has never been tested. So it might be possible there might 
be some issues with it.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Xen GCC coverage ARM64 testing - Unexpected Trap: Data Abort

[Julien Grall]

Hi,

On 5/2/19 3:50 PM, Viktor Mitin wrote:
> Adding Xen maintainers to this email CC.
> 
> Thanks
> 
> On Thu, May 2, 2019 at 5:08 PM Viktor Mitin <viktor.mitin.19@gmail.com> wrote:
>>
>> Hi All,
>>
>> Please be aware that we have tried Xen ARM64 build with
>> CONFIG_COVERAGE feature enabled. The build environment is next:
>> Xen Versions tested: xen-4.12-stable, xen-4.13-staging
>> Board: H3ULCB, R-Car H3 Ver.2.0
>> Poky: Yocto Project Reference Distro 2.4.2
>> Compiler: aarch64-poky-linux-gcc (Linaro GCC 7.2-2017.11) 7.2.1
>>
>> Both Xen versions (4.12 and staging) return "Unexpected Trap: Data
>> Abort" issue in case of 'xencov reset' or 'xencov read' calls:
>>
>> root@h3ulcb:~# xencov reset
>> (XEN) Data Abort Trap. Syndrome=0x7

Per the value, the syndrome is invalid. As I will not open a zip (see 
below why), could you post the full stack trace?

>> (XEN) Walking Hypervisor VA 0x361700 on CPU3 via TTBR 0x0000000078266000
>> (XEN) 0TH[0x0] = 0x0000000078265f7f
>> (XEN) 1ST[0x0] = 0x0000000078262f7f
>> (XEN) 2ND[0x1] = 0x004000007825ff7f
>> (XEN) 3RD[0x161] = 0x00600000781e1f7e
>> (XEN) CPU3: Unexpected Trap: Data Abort
>>
>> Attaching the next log files (zipped in
>> xen_with_config_coverage_logs.zip) with the details:

Please don't send a 54KB attachment on the mailing list. This is using 
up space for every one on the ML. Instead you should upload somewhere 
(e.g pastebin).

But I am afraid, I am not going to open any archive sent on the mailing 
list. Please upload file separately. However....

>> - all the run-time exception details (rcarh3_config_coverage_trap.log);
>> - xen package build log file with compilation options (compilation.log);

This is not necessary.

>> - xen hypervisor .config file used for the build (xen_dot_config.log);
>>
>> Please share any comments or ideas about the issue.

GCOV on Arm has never been tested. So it might be possible there might 
be some issues with it.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: Xen GCC coverage ARM64 testing - Unexpected Trap: Data Abort

[Viktor Mitin]

Hi Julien,

Please find trace log below:

root@h3ulcb:~# xencov reset
(XEN) Data Abort Trap. Syndrome=0x7
(XEN) Walking Hypervisor VA 0x361700 on CPU3 via TTBR 0x0000000078266000
(XEN) 0TH[0x0] = 0x0000000078265f7f
(XEN) 1ST[0x0] = 0x0000000078262f7f
(XEN) 2ND[0x1] = 0x004000007825ff7f
(XEN) 3RD[0x161] = 0x00600000781e1f7e
(XEN) CPU3: Unexpected Trap: Data Abort
(XEN) ----[ Xen-4.13-unstable  arm64  debug=y Not tainted ]----
(XEN) CPU:    3
(XEN) PC:     000000000027bd10 gcov_info_reset+0/0x100
(XEN) LR:     000000000027bbd8
(XEN) SP:     000080037ff07c80
(XEN) CPSR:   60000249 MODE:64-bit EL2h (Hypervisor, handler)
(XEN)    X0: 0000000000361698  X1: 00000000003b0d80  X2: 0000000000000047
(XEN)    X3: 0000000000000020  X4: 0000000000000000  X5: 0000000000000040
(XEN)    X6: 000000000000003f  X7: 0000000000000000  X8: 00000000003b2e40
(XEN)    X9: 0000000000000000 X10: 0000000000000000 X11: 0000000000000000
(XEN)   X12: 0000000000000000 X13: 0000000000000000 X14: 0000000000000000
(XEN)   X15: 0000ffffa12a5d00 X16: 0000000000000023 X17: 0000ffffa12670a0
(XEN)   X18: 0000000000000530 X19: 00000000003b0ba8 X20: 0000000000361698
(XEN)   X21: 00000000003b0c18 X22: 00000000003fb820 X23: 000000000031e698
(XEN)   X24: 0000ffffc598aac0 X25: 0000000000000124 X26: 000000000000001d
(XEN)   X27: ffff000008b11000 X28: ffff8006e98e8000  FP: ffff00000e8abd50
(XEN)
(XEN) VTCR_EL2: 80043594
(XEN)  VTTBR_EL2: 000100073ffc5000
(XEN)
(XEN)  SCTLR_EL2: 30cd183d
(XEN) HCR_EL2: 000000008078663f
(XEN)  TTBR0_EL2: 0000000078266000
(XEN)
(XEN) ESR_EL2: 96000007
(XEN)  HPFAR_EL2: 0000000000000000
(XEN) FAR_EL2: 0000000000361700
(XEN)
(XEN) Xen stack trace from sp=000080037ff07c80:
(XEN) 00000000003b0ba8 0000ffffa1451010 00000000003ad558 000000000027b674
(XEN) 0000000000000000 0000ffffa1451010 000000000026b1ac 0000ffffa1451010
(XEN) 000000000026a280 000000000026a1c4 000080037ff07eb0 00000000003f44f0
(XEN) 00000000003f4c80 000080037ff07f30 000000005a000ea1 0000ffffc598aac0
(XEN) 0000000000000124 000000000028aa5c 000080037ffc7000 00000000003b8a78
(XEN) 00000000002a8cd8 000000097e6cf99f 000000000028b12c 000000000028b090
(XEN) 00000000003b8f38 000080037feed000 000080037ffc7000 000000000028baec
(XEN) 000080037ffc7000 000080037feed000 00000000003a6a28 000000000025d898
(XEN) 00000000003a8700 0000000000000003 00000000003acdd0 0000000000000003
(XEN) 000080037ffd8308 00000000002b0cc0 00000000003f5118 0000001200000014
(XEN) 0000000000000002 ffffffffffffffff 0000000000000000 0000000000000000
(XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN) 000000005a000ea1 000080037ff07eb0 ffff000008b11000 0000000020000145
(XEN) 00000000002abd64 ffff000009169000 ffff8006edb15668 ffff8006ec193c00
(XEN) 000080037ff07fb8 000080037feeddf0 00000000002c342c ffff000009169000
(XEN) 00000000002c3430 9393004760000249 0000ffffa1451010 0000000000000000
(XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN) ffff00000e8abe00 0000000000000000 0000000000000000 0000000000000200
(XEN) 0101010101010101 0000000000000000 0000000000000000 0000000000000000
(XEN) 0000ffffa12b2d98 0000ffffa12a5d00 0000000000000023 0000ffffa12670a0
(XEN) 0000000000000530 ffff8006edb15668 ffff8006ec193c00 ffff8006ec193c00
(XEN) 0000ffffc598aac0 0000000000305000 0000ffffc598aac0 0000000000000124
(XEN) 000000000000001d ffff000008b11000 ffff8006e98e8000 ffff00000e8abd50
(XEN) ffff000008551a10 ffffffffffffffff ffff0000080c1eec 5a000ea120000145
(XEN) 0000000080000000 0000000000000000 0000000000000000 ffff8006e98e8000
(XEN) ffff00000e8abd50 0000ffffa13664dc 0000000000000000 0000000000000000
(XEN) Xen call trace:
(XEN) [<000000000027bd10>] gcov_info_reset+0/0x100 (PC)
(XEN) [<000000000027bbd8>] gcov.c#gcov_reset_all_counters+0x3c/0x78 (LR)
(XEN)
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 3:
(XEN) CPU3: Unexpected Trap: Data Abort
(XEN) ****************************************
(XEN)
(XEN) Reboot in five seconds...
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) PSCI cpu off failed for CPU0 err=-3
(XEN) ****************************************
(XEN)
(XEN) Reboot in five seconds...

Thanks

On Thu, May 2, 2019 at 6:17 PM Julien Grall <julien.grall@arm.com> wrote:
>
> Hi,
>
> On 5/2/19 3:50 PM, Viktor Mitin wrote:
> > Adding Xen maintainers to this email CC.
> >
> > Thanks
> >
> > On Thu, May 2, 2019 at 5:08 PM Viktor Mitin <viktor.mitin.19@gmail.com> wrote:
> >>
> >> Hi All,
> >>
> >> Please be aware that we have tried Xen ARM64 build with
> >> CONFIG_COVERAGE feature enabled. The build environment is next:
> >> Xen Versions tested: xen-4.12-stable, xen-4.13-staging
> >> Board: H3ULCB, R-Car H3 Ver.2.0
> >> Poky: Yocto Project Reference Distro 2.4.2
> >> Compiler: aarch64-poky-linux-gcc (Linaro GCC 7.2-2017.11) 7.2.1
> >>
> >> Both Xen versions (4.12 and staging) return "Unexpected Trap: Data
> >> Abort" issue in case of 'xencov reset' or 'xencov read' calls:
> >>
> >> root@h3ulcb:~# xencov reset
> >> (XEN) Data Abort Trap. Syndrome=0x7
>
> Per the value, the syndrome is invalid. As I will not open a zip (see
> below why), could you post the full stack trace?
>
> >> (XEN) Walking Hypervisor VA 0x361700 on CPU3 via TTBR 0x0000000078266000
> >> (XEN) 0TH[0x0] = 0x0000000078265f7f
> >> (XEN) 1ST[0x0] = 0x0000000078262f7f
> >> (XEN) 2ND[0x1] = 0x004000007825ff7f
> >> (XEN) 3RD[0x161] = 0x00600000781e1f7e
> >> (XEN) CPU3: Unexpected Trap: Data Abort
> >>
> >> Attaching the next log files (zipped in
> >> xen_with_config_coverage_logs.zip) with the details:
>
> Please don't send a 54KB attachment on the mailing list. This is using
> up space for every one on the ML. Instead you should upload somewhere
> (e.g pastebin).
>
> But I am afraid, I am not going to open any archive sent on the mailing
> list. Please upload file separately. However....
>
> >> - all the run-time exception details (rcarh3_config_coverage_trap.log);
> >> - xen package build log file with compilation options (compilation.log);
>
> This is not necessary.
>
> >> - xen hypervisor .config file used for the build (xen_dot_config.log);
> >>
> >> Please share any comments or ideas about the issue.
>
> GCOV on Arm has never been tested. So it might be possible there might
> be some issues with it.
>
> Cheers,
>
> --
> Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Xen GCC coverage ARM64 testing - Unexpected Trap: Data Abort

[Viktor Mitin]

Hi Julien,

Please find trace log below:

root@h3ulcb:~# xencov reset
(XEN) Data Abort Trap. Syndrome=0x7
(XEN) Walking Hypervisor VA 0x361700 on CPU3 via TTBR 0x0000000078266000
(XEN) 0TH[0x0] = 0x0000000078265f7f
(XEN) 1ST[0x0] = 0x0000000078262f7f
(XEN) 2ND[0x1] = 0x004000007825ff7f
(XEN) 3RD[0x161] = 0x00600000781e1f7e
(XEN) CPU3: Unexpected Trap: Data Abort
(XEN) ----[ Xen-4.13-unstable  arm64  debug=y Not tainted ]----
(XEN) CPU:    3
(XEN) PC:     000000000027bd10 gcov_info_reset+0/0x100
(XEN) LR:     000000000027bbd8
(XEN) SP:     000080037ff07c80
(XEN) CPSR:   60000249 MODE:64-bit EL2h (Hypervisor, handler)
(XEN)    X0: 0000000000361698  X1: 00000000003b0d80  X2: 0000000000000047
(XEN)    X3: 0000000000000020  X4: 0000000000000000  X5: 0000000000000040
(XEN)    X6: 000000000000003f  X7: 0000000000000000  X8: 00000000003b2e40
(XEN)    X9: 0000000000000000 X10: 0000000000000000 X11: 0000000000000000
(XEN)   X12: 0000000000000000 X13: 0000000000000000 X14: 0000000000000000
(XEN)   X15: 0000ffffa12a5d00 X16: 0000000000000023 X17: 0000ffffa12670a0
(XEN)   X18: 0000000000000530 X19: 00000000003b0ba8 X20: 0000000000361698
(XEN)   X21: 00000000003b0c18 X22: 00000000003fb820 X23: 000000000031e698
(XEN)   X24: 0000ffffc598aac0 X25: 0000000000000124 X26: 000000000000001d
(XEN)   X27: ffff000008b11000 X28: ffff8006e98e8000  FP: ffff00000e8abd50
(XEN)
(XEN) VTCR_EL2: 80043594
(XEN)  VTTBR_EL2: 000100073ffc5000
(XEN)
(XEN)  SCTLR_EL2: 30cd183d
(XEN) HCR_EL2: 000000008078663f
(XEN)  TTBR0_EL2: 0000000078266000
(XEN)
(XEN) ESR_EL2: 96000007
(XEN)  HPFAR_EL2: 0000000000000000
(XEN) FAR_EL2: 0000000000361700
(XEN)
(XEN) Xen stack trace from sp=000080037ff07c80:
(XEN) 00000000003b0ba8 0000ffffa1451010 00000000003ad558 000000000027b674
(XEN) 0000000000000000 0000ffffa1451010 000000000026b1ac 0000ffffa1451010
(XEN) 000000000026a280 000000000026a1c4 000080037ff07eb0 00000000003f44f0
(XEN) 00000000003f4c80 000080037ff07f30 000000005a000ea1 0000ffffc598aac0
(XEN) 0000000000000124 000000000028aa5c 000080037ffc7000 00000000003b8a78
(XEN) 00000000002a8cd8 000000097e6cf99f 000000000028b12c 000000000028b090
(XEN) 00000000003b8f38 000080037feed000 000080037ffc7000 000000000028baec
(XEN) 000080037ffc7000 000080037feed000 00000000003a6a28 000000000025d898
(XEN) 00000000003a8700 0000000000000003 00000000003acdd0 0000000000000003
(XEN) 000080037ffd8308 00000000002b0cc0 00000000003f5118 0000001200000014
(XEN) 0000000000000002 ffffffffffffffff 0000000000000000 0000000000000000
(XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN) 000000005a000ea1 000080037ff07eb0 ffff000008b11000 0000000020000145
(XEN) 00000000002abd64 ffff000009169000 ffff8006edb15668 ffff8006ec193c00
(XEN) 000080037ff07fb8 000080037feeddf0 00000000002c342c ffff000009169000
(XEN) 00000000002c3430 9393004760000249 0000ffffa1451010 0000000000000000
(XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN) ffff00000e8abe00 0000000000000000 0000000000000000 0000000000000200
(XEN) 0101010101010101 0000000000000000 0000000000000000 0000000000000000
(XEN) 0000ffffa12b2d98 0000ffffa12a5d00 0000000000000023 0000ffffa12670a0
(XEN) 0000000000000530 ffff8006edb15668 ffff8006ec193c00 ffff8006ec193c00
(XEN) 0000ffffc598aac0 0000000000305000 0000ffffc598aac0 0000000000000124
(XEN) 000000000000001d ffff000008b11000 ffff8006e98e8000 ffff00000e8abd50
(XEN) ffff000008551a10 ffffffffffffffff ffff0000080c1eec 5a000ea120000145
(XEN) 0000000080000000 0000000000000000 0000000000000000 ffff8006e98e8000
(XEN) ffff00000e8abd50 0000ffffa13664dc 0000000000000000 0000000000000000
(XEN) Xen call trace:
(XEN) [<000000000027bd10>] gcov_info_reset+0/0x100 (PC)
(XEN) [<000000000027bbd8>] gcov.c#gcov_reset_all_counters+0x3c/0x78 (LR)
(XEN)
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 3:
(XEN) CPU3: Unexpected Trap: Data Abort
(XEN) ****************************************
(XEN)
(XEN) Reboot in five seconds...
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) PSCI cpu off failed for CPU0 err=-3
(XEN) ****************************************
(XEN)
(XEN) Reboot in five seconds...

Thanks

On Thu, May 2, 2019 at 6:17 PM Julien Grall <julien.grall@arm.com> wrote:
>
> Hi,
>
> On 5/2/19 3:50 PM, Viktor Mitin wrote:
> > Adding Xen maintainers to this email CC.
> >
> > Thanks
> >
> > On Thu, May 2, 2019 at 5:08 PM Viktor Mitin <viktor.mitin.19@gmail.com> wrote:
> >>
> >> Hi All,
> >>
> >> Please be aware that we have tried Xen ARM64 build with
> >> CONFIG_COVERAGE feature enabled. The build environment is next:
> >> Xen Versions tested: xen-4.12-stable, xen-4.13-staging
> >> Board: H3ULCB, R-Car H3 Ver.2.0
> >> Poky: Yocto Project Reference Distro 2.4.2
> >> Compiler: aarch64-poky-linux-gcc (Linaro GCC 7.2-2017.11) 7.2.1
> >>
> >> Both Xen versions (4.12 and staging) return "Unexpected Trap: Data
> >> Abort" issue in case of 'xencov reset' or 'xencov read' calls:
> >>
> >> root@h3ulcb:~# xencov reset
> >> (XEN) Data Abort Trap. Syndrome=0x7
>
> Per the value, the syndrome is invalid. As I will not open a zip (see
> below why), could you post the full stack trace?
>
> >> (XEN) Walking Hypervisor VA 0x361700 on CPU3 via TTBR 0x0000000078266000
> >> (XEN) 0TH[0x0] = 0x0000000078265f7f
> >> (XEN) 1ST[0x0] = 0x0000000078262f7f
> >> (XEN) 2ND[0x1] = 0x004000007825ff7f
> >> (XEN) 3RD[0x161] = 0x00600000781e1f7e
> >> (XEN) CPU3: Unexpected Trap: Data Abort
> >>
> >> Attaching the next log files (zipped in
> >> xen_with_config_coverage_logs.zip) with the details:
>
> Please don't send a 54KB attachment on the mailing list. This is using
> up space for every one on the ML. Instead you should upload somewhere
> (e.g pastebin).
>
> But I am afraid, I am not going to open any archive sent on the mailing
> list. Please upload file separately. However....
>
> >> - all the run-time exception details (rcarh3_config_coverage_trap.log);
> >> - xen package build log file with compilation options (compilation.log);
>
> This is not necessary.
>
> >> - xen hypervisor .config file used for the build (xen_dot_config.log);
> >>
> >> Please share any comments or ideas about the issue.
>
> GCOV on Arm has never been tested. So it might be possible there might
> be some issues with it.
>
> Cheers,
>
> --
> Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: Xen GCC coverage ARM64 testing - Unexpected Trap: Data Abort

[Julien Grall]

(+ Wei)

On 5/2/19 5:55 PM, Viktor Mitin wrote:
> Hi Julien,

Hi,

> Please find trace log below:
> 
> root@h3ulcb:~# xencov reset
> (XEN) Data Abort Trap. Syndrome=0x7
> (XEN) Walking Hypervisor VA 0x361700 on CPU3 via TTBR 0x0000000078266000
So this is a data abort when trying to access VA 0x361700 (it is part of 
Xen itself). I misread the Arm Arm before, while ISV is 0 DFSC will 
still provide a correct value. So here we have a "Translation fault, 
level 3".

Which makes sense because ...


> (XEN) 0TH[0x0] = 0x0000000078265f7f
> (XEN) 1ST[0x0] = 0x0000000078262f7f
> (XEN) 2ND[0x1] = 0x004000007825ff7f
> (XEN) 3RD[0x161] = 0x00600000781e1f7e

the 3rd entry is not valid. I managed to reduce the error and it looks 
like gcov is trying to access a counter in the section init.data.

As all the .init.* sections are stripped after boot, it means that 
anything in .init.data cannot be accessed anymore.

Wei, how do you deal with counters in init.data on x86?

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Xen GCC coverage ARM64 testing - Unexpected Trap: Data Abort

[Julien Grall]

(+ Wei)

On 5/2/19 5:55 PM, Viktor Mitin wrote:
> Hi Julien,

Hi,

> Please find trace log below:
> 
> root@h3ulcb:~# xencov reset
> (XEN) Data Abort Trap. Syndrome=0x7
> (XEN) Walking Hypervisor VA 0x361700 on CPU3 via TTBR 0x0000000078266000
So this is a data abort when trying to access VA 0x361700 (it is part of 
Xen itself). I misread the Arm Arm before, while ISV is 0 DFSC will 
still provide a correct value. So here we have a "Translation fault, 
level 3".

Which makes sense because ...


> (XEN) 0TH[0x0] = 0x0000000078265f7f
> (XEN) 1ST[0x0] = 0x0000000078262f7f
> (XEN) 2ND[0x1] = 0x004000007825ff7f
> (XEN) 3RD[0x161] = 0x00600000781e1f7e

the 3rd entry is not valid. I managed to reduce the error and it looks 
like gcov is trying to access a counter in the section init.data.

As all the .init.* sections are stripped after boot, it means that 
anything in .init.data cannot be accessed anymore.

Wei, how do you deal with counters in init.data on x86?

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: Xen GCC coverage ARM64 testing - Unexpected Trap: Data Abort

[Wei Liu]

On Thu, May 02, 2019 at 09:43:17PM +0100, Julien Grall wrote:
> (+ Wei)
> 
> On 5/2/19 5:55 PM, Viktor Mitin wrote:
> > Hi Julien,
> 
> Hi,
> 
> > Please find trace log below:
> > 
> > root@h3ulcb:~# xencov reset
> > (XEN) Data Abort Trap. Syndrome=0x7
> > (XEN) Walking Hypervisor VA 0x361700 on CPU3 via TTBR 0x0000000078266000
> So this is a data abort when trying to access VA 0x361700 (it is part of Xen
> itself). I misread the Arm Arm before, while ISV is 0 DFSC will still
> provide a correct value. So here we have a "Translation fault, level 3".
> 
> Which makes sense because ...
> 
> 
> > (XEN) 0TH[0x0] = 0x0000000078265f7f
> > (XEN) 1ST[0x0] = 0x0000000078262f7f
> > (XEN) 2ND[0x1] = 0x004000007825ff7f
> > (XEN) 3RD[0x161] = 0x00600000781e1f7e
> 
> the 3rd entry is not valid. I managed to reduce the error and it looks like
> gcov is trying to access a counter in the section init.data.
> 
> As all the .init.* sections are stripped after boot, it means that anything
> in .init.data cannot be accessed anymore.
> 
> Wei, how do you deal with counters in init.data on x86?

The build system explicitly compile any .init binary without gcov
option. So maybe some file was not correctly added?

Wei.


> 
> Cheers,
> 
> -- 
> Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Xen GCC coverage ARM64 testing - Unexpected Trap: Data Abort

[Wei Liu]

On Thu, May 02, 2019 at 09:43:17PM +0100, Julien Grall wrote:
> (+ Wei)
> 
> On 5/2/19 5:55 PM, Viktor Mitin wrote:
> > Hi Julien,
> 
> Hi,
> 
> > Please find trace log below:
> > 
> > root@h3ulcb:~# xencov reset
> > (XEN) Data Abort Trap. Syndrome=0x7
> > (XEN) Walking Hypervisor VA 0x361700 on CPU3 via TTBR 0x0000000078266000
> So this is a data abort when trying to access VA 0x361700 (it is part of Xen
> itself). I misread the Arm Arm before, while ISV is 0 DFSC will still
> provide a correct value. So here we have a "Translation fault, level 3".
> 
> Which makes sense because ...
> 
> 
> > (XEN) 0TH[0x0] = 0x0000000078265f7f
> > (XEN) 1ST[0x0] = 0x0000000078262f7f
> > (XEN) 2ND[0x1] = 0x004000007825ff7f
> > (XEN) 3RD[0x161] = 0x00600000781e1f7e
> 
> the 3rd entry is not valid. I managed to reduce the error and it looks like
> gcov is trying to access a counter in the section init.data.
> 
> As all the .init.* sections are stripped after boot, it means that anything
> in .init.data cannot be accessed anymore.
> 
> Wei, how do you deal with counters in init.data on x86?

The build system explicitly compile any .init binary without gcov
option. So maybe some file was not correctly added?

Wei.


> 
> Cheers,
> 
> -- 
> Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: Xen GCC coverage ARM64 testing - Unexpected Trap: Data Abort

[Julien Grall]

Hi Wei,

On 5/3/19 12:08 PM, Wei Liu wrote:
> On Thu, May 02, 2019 at 09:43:17PM +0100, Julien Grall wrote:
>> (+ Wei)
>>
>> On 5/2/19 5:55 PM, Viktor Mitin wrote:
>>> Hi Julien,
>>
>> Hi,
>>
>>> Please find trace log below:
>>>
>>> root@h3ulcb:~# xencov reset
>>> (XEN) Data Abort Trap. Syndrome=0x7
>>> (XEN) Walking Hypervisor VA 0x361700 on CPU3 via TTBR 0x0000000078266000
>> So this is a data abort when trying to access VA 0x361700 (it is part of Xen
>> itself). I misread the Arm Arm before, while ISV is 0 DFSC will still
>> provide a correct value. So here we have a "Translation fault, level 3".
>>
>> Which makes sense because ...
>>
>>
>>> (XEN) 0TH[0x0] = 0x0000000078265f7f
>>> (XEN) 1ST[0x0] = 0x0000000078262f7f
>>> (XEN) 2ND[0x1] = 0x004000007825ff7f
>>> (XEN) 3RD[0x161] = 0x00600000781e1f7e
>>
>> the 3rd entry is not valid. I managed to reduce the error and it looks like
>> gcov is trying to access a counter in the section init.data.
>>
>> As all the .init.* sections are stripped after boot, it means that anything
>> in .init.data cannot be accessed anymore.
>>
>> Wei, how do you deal with counters in init.data on x86?
> 
> The build system explicitly compile any .init binary without gcov
> option. So maybe some file was not correctly added?

Thank you for the pointer. The problem is coming from libfdt. The entire 
library is moved to .init using:

  $(OBJCOPY) $(foreach s,$(SECTIONS),--rename-section .$(s)=.init.$(s)) 
$< $@

So we need to tell the top Makefile to filter out libfdt. The patch 
below should do the job:

diff --git a/xen/common/libfdt/Makefile b/xen/common/libfdt/Makefile
index d81f54b6b8..c075bbf546 100644
--- a/xen/common/libfdt/Makefile
+++ b/xen/common/libfdt/Makefile
@@ -3,6 +3,7 @@ include Makefile.libfdt
  SECTIONS := text data $(SPECIAL_DATA_SECTIONS)

  obj-y += libfdt.o
+nocov-y += libfdt.o

  CFLAGS += -I$(BASEDIR)/include/xen/libfdt/

While looking at the code, I noticed libelf is also built with coverage 
but in .init section. So I would expect the same error on x86, did you 
try "xencov reset" on x86?

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Xen GCC coverage ARM64 testing - Unexpected Trap: Data Abort

[Julien Grall]

Hi Wei,

On 5/3/19 12:08 PM, Wei Liu wrote:
> On Thu, May 02, 2019 at 09:43:17PM +0100, Julien Grall wrote:
>> (+ Wei)
>>
>> On 5/2/19 5:55 PM, Viktor Mitin wrote:
>>> Hi Julien,
>>
>> Hi,
>>
>>> Please find trace log below:
>>>
>>> root@h3ulcb:~# xencov reset
>>> (XEN) Data Abort Trap. Syndrome=0x7
>>> (XEN) Walking Hypervisor VA 0x361700 on CPU3 via TTBR 0x0000000078266000
>> So this is a data abort when trying to access VA 0x361700 (it is part of Xen
>> itself). I misread the Arm Arm before, while ISV is 0 DFSC will still
>> provide a correct value. So here we have a "Translation fault, level 3".
>>
>> Which makes sense because ...
>>
>>
>>> (XEN) 0TH[0x0] = 0x0000000078265f7f
>>> (XEN) 1ST[0x0] = 0x0000000078262f7f
>>> (XEN) 2ND[0x1] = 0x004000007825ff7f
>>> (XEN) 3RD[0x161] = 0x00600000781e1f7e
>>
>> the 3rd entry is not valid. I managed to reduce the error and it looks like
>> gcov is trying to access a counter in the section init.data.
>>
>> As all the .init.* sections are stripped after boot, it means that anything
>> in .init.data cannot be accessed anymore.
>>
>> Wei, how do you deal with counters in init.data on x86?
> 
> The build system explicitly compile any .init binary without gcov
> option. So maybe some file was not correctly added?

Thank you for the pointer. The problem is coming from libfdt. The entire 
library is moved to .init using:

  $(OBJCOPY) $(foreach s,$(SECTIONS),--rename-section .$(s)=.init.$(s)) 
$< $@

So we need to tell the top Makefile to filter out libfdt. The patch 
below should do the job:

diff --git a/xen/common/libfdt/Makefile b/xen/common/libfdt/Makefile
index d81f54b6b8..c075bbf546 100644
--- a/xen/common/libfdt/Makefile
+++ b/xen/common/libfdt/Makefile
@@ -3,6 +3,7 @@ include Makefile.libfdt
  SECTIONS := text data $(SPECIAL_DATA_SECTIONS)

  obj-y += libfdt.o
+nocov-y += libfdt.o

  CFLAGS += -I$(BASEDIR)/include/xen/libfdt/

While looking at the code, I noticed libelf is also built with coverage 
but in .init section. So I would expect the same error on x86, did you 
try "xencov reset" on x86?

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: Xen GCC coverage ARM64 testing - Unexpected Trap: Data Abort

[Wei Liu]

On Fri, May 03, 2019 at 02:35:08PM +0100, Julien Grall wrote:
> Hi Wei,
> 
> On 5/3/19 12:08 PM, Wei Liu wrote:
> > On Thu, May 02, 2019 at 09:43:17PM +0100, Julien Grall wrote:
> > > (+ Wei)
> > > 
> > > On 5/2/19 5:55 PM, Viktor Mitin wrote:
> > > > Hi Julien,
> > > 
> > > Hi,
> > > 
> > > > Please find trace log below:
> > > > 
> > > > root@h3ulcb:~# xencov reset
> > > > (XEN) Data Abort Trap. Syndrome=0x7
> > > > (XEN) Walking Hypervisor VA 0x361700 on CPU3 via TTBR 0x0000000078266000
> > > So this is a data abort when trying to access VA 0x361700 (it is part of Xen
> > > itself). I misread the Arm Arm before, while ISV is 0 DFSC will still
> > > provide a correct value. So here we have a "Translation fault, level 3".
> > > 
> > > Which makes sense because ...
> > > 
> > > 
> > > > (XEN) 0TH[0x0] = 0x0000000078265f7f
> > > > (XEN) 1ST[0x0] = 0x0000000078262f7f
> > > > (XEN) 2ND[0x1] = 0x004000007825ff7f
> > > > (XEN) 3RD[0x161] = 0x00600000781e1f7e
> > > 
> > > the 3rd entry is not valid. I managed to reduce the error and it looks like
> > > gcov is trying to access a counter in the section init.data.
> > > 
> > > As all the .init.* sections are stripped after boot, it means that anything
> > > in .init.data cannot be accessed anymore.
> > > 
> > > Wei, how do you deal with counters in init.data on x86?
> > 
> > The build system explicitly compile any .init binary without gcov
> > option. So maybe some file was not correctly added?
> 
> Thank you for the pointer. The problem is coming from libfdt. The entire
> library is moved to .init using:
> 
>  $(OBJCOPY) $(foreach s,$(SECTIONS),--rename-section .$(s)=.init.$(s)) $< $@
> 
> So we need to tell the top Makefile to filter out libfdt. The patch below
> should do the job:
> 
> diff --git a/xen/common/libfdt/Makefile b/xen/common/libfdt/Makefile
> index d81f54b6b8..c075bbf546 100644
> --- a/xen/common/libfdt/Makefile
> +++ b/xen/common/libfdt/Makefile
> @@ -3,6 +3,7 @@ include Makefile.libfdt
>  SECTIONS := text data $(SPECIAL_DATA_SECTIONS)
> 
>  obj-y += libfdt.o
> +nocov-y += libfdt.o
> 
>  CFLAGS += -I$(BASEDIR)/include/xen/libfdt/
> 
> While looking at the code, I noticed libelf is also built with coverage but
> in .init section. So I would expect the same error on x86, did you try
> "xencov reset" on x86?

I did. It worked. Though at this point I'm not sure why it worked. :-/

Wei.

> 
> Cheers,
> 
> -- 
> Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Xen GCC coverage ARM64 testing - Unexpected Trap: Data Abort

[Wei Liu]

On Fri, May 03, 2019 at 02:35:08PM +0100, Julien Grall wrote:
> Hi Wei,
> 
> On 5/3/19 12:08 PM, Wei Liu wrote:
> > On Thu, May 02, 2019 at 09:43:17PM +0100, Julien Grall wrote:
> > > (+ Wei)
> > > 
> > > On 5/2/19 5:55 PM, Viktor Mitin wrote:
> > > > Hi Julien,
> > > 
> > > Hi,
> > > 
> > > > Please find trace log below:
> > > > 
> > > > root@h3ulcb:~# xencov reset
> > > > (XEN) Data Abort Trap. Syndrome=0x7
> > > > (XEN) Walking Hypervisor VA 0x361700 on CPU3 via TTBR 0x0000000078266000
> > > So this is a data abort when trying to access VA 0x361700 (it is part of Xen
> > > itself). I misread the Arm Arm before, while ISV is 0 DFSC will still
> > > provide a correct value. So here we have a "Translation fault, level 3".
> > > 
> > > Which makes sense because ...
> > > 
> > > 
> > > > (XEN) 0TH[0x0] = 0x0000000078265f7f
> > > > (XEN) 1ST[0x0] = 0x0000000078262f7f
> > > > (XEN) 2ND[0x1] = 0x004000007825ff7f
> > > > (XEN) 3RD[0x161] = 0x00600000781e1f7e
> > > 
> > > the 3rd entry is not valid. I managed to reduce the error and it looks like
> > > gcov is trying to access a counter in the section init.data.
> > > 
> > > As all the .init.* sections are stripped after boot, it means that anything
> > > in .init.data cannot be accessed anymore.
> > > 
> > > Wei, how do you deal with counters in init.data on x86?
> > 
> > The build system explicitly compile any .init binary without gcov
> > option. So maybe some file was not correctly added?
> 
> Thank you for the pointer. The problem is coming from libfdt. The entire
> library is moved to .init using:
> 
>  $(OBJCOPY) $(foreach s,$(SECTIONS),--rename-section .$(s)=.init.$(s)) $< $@
> 
> So we need to tell the top Makefile to filter out libfdt. The patch below
> should do the job:
> 
> diff --git a/xen/common/libfdt/Makefile b/xen/common/libfdt/Makefile
> index d81f54b6b8..c075bbf546 100644
> --- a/xen/common/libfdt/Makefile
> +++ b/xen/common/libfdt/Makefile
> @@ -3,6 +3,7 @@ include Makefile.libfdt
>  SECTIONS := text data $(SPECIAL_DATA_SECTIONS)
> 
>  obj-y += libfdt.o
> +nocov-y += libfdt.o
> 
>  CFLAGS += -I$(BASEDIR)/include/xen/libfdt/
> 
> While looking at the code, I noticed libelf is also built with coverage but
> in .init section. So I would expect the same error on x86, did you try
> "xencov reset" on x86?

I did. It worked. Though at this point I'm not sure why it worked. :-/

Wei.

> 
> Cheers,
> 
> -- 
> Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: Xen GCC coverage ARM64 testing - Unexpected Trap: Data Abort

[Julien Grall]

Hi,

On 03/05/2019 14:41, Wei Liu wrote:
> On Fri, May 03, 2019 at 02:35:08PM +0100, Julien Grall wrote:
>> Hi Wei,
>>
>> On 5/3/19 12:08 PM, Wei Liu wrote:
>>> On Thu, May 02, 2019 at 09:43:17PM +0100, Julien Grall wrote:
>>>> (+ Wei)
>>>>
>>>> On 5/2/19 5:55 PM, Viktor Mitin wrote:
>>>>> Hi Julien,
>>>>
>>>> Hi,
>>>>
>>>>> Please find trace log below:
>>>>>
>>>>> root@h3ulcb:~# xencov reset
>>>>> (XEN) Data Abort Trap. Syndrome=0x7
>>>>> (XEN) Walking Hypervisor VA 0x361700 on CPU3 via TTBR 0x0000000078266000
>>>> So this is a data abort when trying to access VA 0x361700 (it is part of Xen
>>>> itself). I misread the Arm Arm before, while ISV is 0 DFSC will still
>>>> provide a correct value. So here we have a "Translation fault, level 3".
>>>>
>>>> Which makes sense because ...
>>>>
>>>>
>>>>> (XEN) 0TH[0x0] = 0x0000000078265f7f
>>>>> (XEN) 1ST[0x0] = 0x0000000078262f7f
>>>>> (XEN) 2ND[0x1] = 0x004000007825ff7f
>>>>> (XEN) 3RD[0x161] = 0x00600000781e1f7e
>>>>
>>>> the 3rd entry is not valid. I managed to reduce the error and it looks like
>>>> gcov is trying to access a counter in the section init.data.
>>>>
>>>> As all the .init.* sections are stripped after boot, it means that anything
>>>> in .init.data cannot be accessed anymore.
>>>>
>>>> Wei, how do you deal with counters in init.data on x86?
>>>
>>> The build system explicitly compile any .init binary without gcov
>>> option. So maybe some file was not correctly added?
>>
>> Thank you for the pointer. The problem is coming from libfdt. The entire
>> library is moved to .init using:
>>
>>   $(OBJCOPY) $(foreach s,$(SECTIONS),--rename-section .$(s)=.init.$(s)) $< $@
>>
>> So we need to tell the top Makefile to filter out libfdt. The patch below
>> should do the job:
>>
>> diff --git a/xen/common/libfdt/Makefile b/xen/common/libfdt/Makefile
>> index d81f54b6b8..c075bbf546 100644
>> --- a/xen/common/libfdt/Makefile
>> +++ b/xen/common/libfdt/Makefile
>> @@ -3,6 +3,7 @@ include Makefile.libfdt
>>   SECTIONS := text data $(SPECIAL_DATA_SECTIONS)
>>
>>   obj-y += libfdt.o
>> +nocov-y += libfdt.o
>>
>>   CFLAGS += -I$(BASEDIR)/include/xen/libfdt/
>>
>> While looking at the code, I noticed libelf is also built with coverage but
>> in .init section. So I would expect the same error on x86, did you try
>> "xencov reset" on x86?
> 
> I did. It worked. Though at this point I'm not sure why it worked. :-/

I think I know why, only the sections .text and .data are prefixed with .init. 
In the case of libelf, none of the GCOV symbols seems to be located in .data.

For libfdt, some of them are located in .data (renamed to .init.data). Hence the 
difference in behavior.

We should probably fixed the two libraries as this is quite fragile for libelf 
as well.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Xen GCC coverage ARM64 testing - Unexpected Trap: Data Abort

[Julien Grall]

Hi,

On 03/05/2019 14:41, Wei Liu wrote:
> On Fri, May 03, 2019 at 02:35:08PM +0100, Julien Grall wrote:
>> Hi Wei,
>>
>> On 5/3/19 12:08 PM, Wei Liu wrote:
>>> On Thu, May 02, 2019 at 09:43:17PM +0100, Julien Grall wrote:
>>>> (+ Wei)
>>>>
>>>> On 5/2/19 5:55 PM, Viktor Mitin wrote:
>>>>> Hi Julien,
>>>>
>>>> Hi,
>>>>
>>>>> Please find trace log below:
>>>>>
>>>>> root@h3ulcb:~# xencov reset
>>>>> (XEN) Data Abort Trap. Syndrome=0x7
>>>>> (XEN) Walking Hypervisor VA 0x361700 on CPU3 via TTBR 0x0000000078266000
>>>> So this is a data abort when trying to access VA 0x361700 (it is part of Xen
>>>> itself). I misread the Arm Arm before, while ISV is 0 DFSC will still
>>>> provide a correct value. So here we have a "Translation fault, level 3".
>>>>
>>>> Which makes sense because ...
>>>>
>>>>
>>>>> (XEN) 0TH[0x0] = 0x0000000078265f7f
>>>>> (XEN) 1ST[0x0] = 0x0000000078262f7f
>>>>> (XEN) 2ND[0x1] = 0x004000007825ff7f
>>>>> (XEN) 3RD[0x161] = 0x00600000781e1f7e
>>>>
>>>> the 3rd entry is not valid. I managed to reduce the error and it looks like
>>>> gcov is trying to access a counter in the section init.data.
>>>>
>>>> As all the .init.* sections are stripped after boot, it means that anything
>>>> in .init.data cannot be accessed anymore.
>>>>
>>>> Wei, how do you deal with counters in init.data on x86?
>>>
>>> The build system explicitly compile any .init binary without gcov
>>> option. So maybe some file was not correctly added?
>>
>> Thank you for the pointer. The problem is coming from libfdt. The entire
>> library is moved to .init using:
>>
>>   $(OBJCOPY) $(foreach s,$(SECTIONS),--rename-section .$(s)=.init.$(s)) $< $@
>>
>> So we need to tell the top Makefile to filter out libfdt. The patch below
>> should do the job:
>>
>> diff --git a/xen/common/libfdt/Makefile b/xen/common/libfdt/Makefile
>> index d81f54b6b8..c075bbf546 100644
>> --- a/xen/common/libfdt/Makefile
>> +++ b/xen/common/libfdt/Makefile
>> @@ -3,6 +3,7 @@ include Makefile.libfdt
>>   SECTIONS := text data $(SPECIAL_DATA_SECTIONS)
>>
>>   obj-y += libfdt.o
>> +nocov-y += libfdt.o
>>
>>   CFLAGS += -I$(BASEDIR)/include/xen/libfdt/
>>
>> While looking at the code, I noticed libelf is also built with coverage but
>> in .init section. So I would expect the same error on x86, did you try
>> "xencov reset" on x86?
> 
> I did. It worked. Though at this point I'm not sure why it worked. :-/

I think I know why, only the sections .text and .data are prefixed with .init. 
In the case of libelf, none of the GCOV symbols seems to be located in .data.

For libfdt, some of them are located in .data (renamed to .init.data). Hence the 
difference in behavior.

We should probably fixed the two libraries as this is quite fragile for libelf 
as well.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: Xen GCC coverage ARM64 testing - Unexpected Trap: Data Abort

[Wei Liu]

On Fri, May 03, 2019 at 03:16:52PM +0100, Julien Grall wrote:
> > > diff --git a/xen/common/libfdt/Makefile b/xen/common/libfdt/Makefile
> > > index d81f54b6b8..c075bbf546 100644
> > > --- a/xen/common/libfdt/Makefile
> > > +++ b/xen/common/libfdt/Makefile
> > > @@ -3,6 +3,7 @@ include Makefile.libfdt
> > >   SECTIONS := text data $(SPECIAL_DATA_SECTIONS)
> > > 
> > >   obj-y += libfdt.o
> > > +nocov-y += libfdt.o
> > > 
> > >   CFLAGS += -I$(BASEDIR)/include/xen/libfdt/
> > > 
> > > While looking at the code, I noticed libelf is also built with coverage but
> > > in .init section. So I would expect the same error on x86, did you try
> > > "xencov reset" on x86?
> > 
> > I did. It worked. Though at this point I'm not sure why it worked. :-/
> 
> I think I know why, only the sections .text and .data are prefixed with
> .init. In the case of libelf, none of the GCOV symbols seems to be located
> in .data.
> 
> For libfdt, some of them are located in .data (renamed to .init.data). Hence
> the difference in behavior.
> 

Thanks for the analysis.

> We should probably fixed the two libraries as this is quite fragile for
> libelf as well.

Sounds good to me.

Wei.

> 
> Cheers,
> 
> -- 
> Julien Grall
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Xen GCC coverage ARM64 testing - Unexpected Trap: Data Abort

[Wei Liu]

On Fri, May 03, 2019 at 03:16:52PM +0100, Julien Grall wrote:
> > > diff --git a/xen/common/libfdt/Makefile b/xen/common/libfdt/Makefile
> > > index d81f54b6b8..c075bbf546 100644
> > > --- a/xen/common/libfdt/Makefile
> > > +++ b/xen/common/libfdt/Makefile
> > > @@ -3,6 +3,7 @@ include Makefile.libfdt
> > >   SECTIONS := text data $(SPECIAL_DATA_SECTIONS)
> > > 
> > >   obj-y += libfdt.o
> > > +nocov-y += libfdt.o
> > > 
> > >   CFLAGS += -I$(BASEDIR)/include/xen/libfdt/
> > > 
> > > While looking at the code, I noticed libelf is also built with coverage but
> > > in .init section. So I would expect the same error on x86, did you try
> > > "xencov reset" on x86?
> > 
> > I did. It worked. Though at this point I'm not sure why it worked. :-/
> 
> I think I know why, only the sections .text and .data are prefixed with
> .init. In the case of libelf, none of the GCOV symbols seems to be located
> in .data.
> 
> For libfdt, some of them are located in .data (renamed to .init.data). Hence
> the difference in behavior.
> 

Thanks for the analysis.

> We should probably fixed the two libraries as this is quite fragile for
> libelf as well.

Sounds good to me.

Wei.

> 
> Cheers,
> 
> -- 
> Julien Grall
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: Xen GCC coverage ARM64 testing - Unexpected Trap: Data Abort

[Viktor Mitin]

Hi Julien,

Please be aware that the patch you proposed (+nocov-y += libfdt.o)
failed to build with the next error (xen 4.12):

aarch64-poky-linux-gcc   -DBUILD_ID -fno-strict-aliasing -std=gnu99
-Wall -Wstrict-prototypes -Wdeclaration-after-statement
-Wno-unused-but-set-variable -Wno-unused-local-typedefs   -O2
-fomit-frame-pointer
-D__XEN_INTERFACE_VERSION__=__XEN_LATEST_INTERFACE_VERSION__ -MMD -MF
.handlereg.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE   -Werror
-Wmissing-prototypes -I./include
-I/home/c/w/rcar_h3_ubuntu1604_yocto/build/tmp/work/aarch64-poky-linux/xen/4.12.0.0+gitAUTOINC+fd2a34c965-r0/git/tools/libs/toolcore/../../../tools/include
 -c -o handlereg.o handlereg.c
aarch64-poky-linux-gcc  -DPIC  -DBUILD_ID -fno-strict-aliasing
-std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement
-Wno-unused-but-set-variable -Wno-unused-local-typedefs   -O2
-fomit-frame-pointer
-D__XEN_INTERFACE_VERSION__=__XEN_LATEST_INTERFACE_VERSION__ -MMD -MF
.handlereg.opic.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE   -Werror
-Wmissing-prototypes -I./include
-I/home/c/w/rcar_h3_ubuntu1604_yocto/build/tmp/work/aarch64-poky-linux/xen/4.12.0.0+gitAUTOINC+fd2a34c965-r0/git/tools/libs/toolcore/../../../tools/include
 -fPIC -c -o handlereg.opic handlereg.c
mkdir -p /home/c/w/rcar_h3_ubuntu1604_yocto/build/tmp/work/aarch64-poky-linux/xen/4.12.0.0+gitAUTOINC+fd2a34c965-r0/git/tools/pkg-config
In file included from ./include/xentoolcore.h:25:0,
                 from ./include/xentoolcore_internal.h:29,
                 from handlereg.c:23:
/home/c/w/rcar_h3_ubuntu1604_yocto/build/tmp/work/aarch64-poky-linux/xen/4.12.0.0+gitAUTOINC+fd2a34c965-r0/recipe-sysroot-native/usr/lib/aarch64-poky-linux/gcc/aarch64-poky-linux/7.2.1/include/stdint.h:9:16:
fatal error: stdint.h: No such file or directory
 # include_next <stdint.h>
                ^~~~~~~~~~
compilation terminated.
In file included from include/xentoolcore.h:25:0,
                 from include/xentoolcore_internal.h:29:
/home/c/w/rcar_h3_ubuntu1604_yocto/build/tmp/work/aarch64-poky-linux/xen/4.12.0.0+gitAUTOINC+fd2a34c965-r0/recipe-sysroot-native/usr/lib/aarch64-poky-linux/gcc/aarch64-poky-linux/7.2.1/include/stdint.h:9:16:
fatal error: stdint.h: No such file or directory
 # include_next <stdint.h>
                ^~~~~~~~~~
compilation terminated.
/home/c/w/rcar_h3_ubuntu1604_yocto/build/tmp/work/aarch64-poky-linux/xen/4.12.0.0+gitAUTOINC+fd2a34c965-r0/git/tools/libs/toolcore/../../../tools/Rules.mk:227:
recipe for target 'handlereg.o' failed
make[7]: *** [handlereg.o] Error 1
make[7]: *** Waiting for unfinished jobs....
/home/c/w/rcar_h3_ubuntu1604_yocto/build/tmp/work/aarch64-poky-linux/xen/4.12.0.0+gitAUTOINC+fd2a34c965-r0/git/tools/libs/toolcore/../../../tools/Rules.mk:238:
recipe for target 'headers.chk' failed
make[7]: *** [headers.chk] Error 1
In file included from ./include/xentoolcore.h:25:0,
                 from ./include/xentoolcore_internal.h:29,
                 from handlereg.c:23:
/home/c/w/rcar_h3_ubuntu1604_yocto/build/tmp/work/aarch64-poky-linux/xen/4.12.0.0+gitAUTOINC+fd2a34c965-r0/recipe-sysroot-native/usr/lib/aarch64-poky-linux/gcc/aarch64-poky-linux/7.2.1/include/stdint.h:9:16:
fatal error: stdint.h: No such file or directory
 # include_next <stdint.h>
                ^~~~~~~~~~
compilation terminated.


Thanks

On Fri, May 3, 2019 at 5:19 PM Wei Liu <wei.liu2@citrix.com> wrote:
>
> On Fri, May 03, 2019 at 03:16:52PM +0100, Julien Grall wrote:
> > > > diff --git a/xen/common/libfdt/Makefile b/xen/common/libfdt/Makefile
> > > > index d81f54b6b8..c075bbf546 100644
> > > > --- a/xen/common/libfdt/Makefile
> > > > +++ b/xen/common/libfdt/Makefile
> > > > @@ -3,6 +3,7 @@ include Makefile.libfdt
> > > >   SECTIONS := text data $(SPECIAL_DATA_SECTIONS)
> > > >
> > > >   obj-y += libfdt.o
> > > > +nocov-y += libfdt.o
> > > >
> > > >   CFLAGS += -I$(BASEDIR)/include/xen/libfdt/
> > > >
> > > > While looking at the code, I noticed libelf is also built with coverage but
> > > > in .init section. So I would expect the same error on x86, did you try
> > > > "xencov reset" on x86?
> > >
> > > I did. It worked. Though at this point I'm not sure why it worked. :-/
> >
> > I think I know why, only the sections .text and .data are prefixed with
> > .init. In the case of libelf, none of the GCOV symbols seems to be located
> > in .data.
> >
> > For libfdt, some of them are located in .data (renamed to .init.data). Hence
> > the difference in behavior.
> >
>
> Thanks for the analysis.
>
> > We should probably fixed the two libraries as this is quite fragile for
> > libelf as well.
>
> Sounds good to me.
>
> Wei.
>
> >
> > Cheers,
> >
> > --
> > Julien Grall
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xenproject.org
> > https://lists.xenproject.org/mailman/listinfo/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Xen GCC coverage ARM64 testing - Unexpected Trap: Data Abort

[Viktor Mitin]

Hi Julien,

Please be aware that the patch you proposed (+nocov-y += libfdt.o)
failed to build with the next error (xen 4.12):

aarch64-poky-linux-gcc   -DBUILD_ID -fno-strict-aliasing -std=gnu99
-Wall -Wstrict-prototypes -Wdeclaration-after-statement
-Wno-unused-but-set-variable -Wno-unused-local-typedefs   -O2
-fomit-frame-pointer
-D__XEN_INTERFACE_VERSION__=__XEN_LATEST_INTERFACE_VERSION__ -MMD -MF
.handlereg.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE   -Werror
-Wmissing-prototypes -I./include
-I/home/c/w/rcar_h3_ubuntu1604_yocto/build/tmp/work/aarch64-poky-linux/xen/4.12.0.0+gitAUTOINC+fd2a34c965-r0/git/tools/libs/toolcore/../../../tools/include
 -c -o handlereg.o handlereg.c
aarch64-poky-linux-gcc  -DPIC  -DBUILD_ID -fno-strict-aliasing
-std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement
-Wno-unused-but-set-variable -Wno-unused-local-typedefs   -O2
-fomit-frame-pointer
-D__XEN_INTERFACE_VERSION__=__XEN_LATEST_INTERFACE_VERSION__ -MMD -MF
.handlereg.opic.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE   -Werror
-Wmissing-prototypes -I./include
-I/home/c/w/rcar_h3_ubuntu1604_yocto/build/tmp/work/aarch64-poky-linux/xen/4.12.0.0+gitAUTOINC+fd2a34c965-r0/git/tools/libs/toolcore/../../../tools/include
 -fPIC -c -o handlereg.opic handlereg.c
mkdir -p /home/c/w/rcar_h3_ubuntu1604_yocto/build/tmp/work/aarch64-poky-linux/xen/4.12.0.0+gitAUTOINC+fd2a34c965-r0/git/tools/pkg-config
In file included from ./include/xentoolcore.h:25:0,
                 from ./include/xentoolcore_internal.h:29,
                 from handlereg.c:23:
/home/c/w/rcar_h3_ubuntu1604_yocto/build/tmp/work/aarch64-poky-linux/xen/4.12.0.0+gitAUTOINC+fd2a34c965-r0/recipe-sysroot-native/usr/lib/aarch64-poky-linux/gcc/aarch64-poky-linux/7.2.1/include/stdint.h:9:16:
fatal error: stdint.h: No such file or directory
 # include_next <stdint.h>
                ^~~~~~~~~~
compilation terminated.
In file included from include/xentoolcore.h:25:0,
                 from include/xentoolcore_internal.h:29:
/home/c/w/rcar_h3_ubuntu1604_yocto/build/tmp/work/aarch64-poky-linux/xen/4.12.0.0+gitAUTOINC+fd2a34c965-r0/recipe-sysroot-native/usr/lib/aarch64-poky-linux/gcc/aarch64-poky-linux/7.2.1/include/stdint.h:9:16:
fatal error: stdint.h: No such file or directory
 # include_next <stdint.h>
                ^~~~~~~~~~
compilation terminated.
/home/c/w/rcar_h3_ubuntu1604_yocto/build/tmp/work/aarch64-poky-linux/xen/4.12.0.0+gitAUTOINC+fd2a34c965-r0/git/tools/libs/toolcore/../../../tools/Rules.mk:227:
recipe for target 'handlereg.o' failed
make[7]: *** [handlereg.o] Error 1
make[7]: *** Waiting for unfinished jobs....
/home/c/w/rcar_h3_ubuntu1604_yocto/build/tmp/work/aarch64-poky-linux/xen/4.12.0.0+gitAUTOINC+fd2a34c965-r0/git/tools/libs/toolcore/../../../tools/Rules.mk:238:
recipe for target 'headers.chk' failed
make[7]: *** [headers.chk] Error 1
In file included from ./include/xentoolcore.h:25:0,
                 from ./include/xentoolcore_internal.h:29,
                 from handlereg.c:23:
/home/c/w/rcar_h3_ubuntu1604_yocto/build/tmp/work/aarch64-poky-linux/xen/4.12.0.0+gitAUTOINC+fd2a34c965-r0/recipe-sysroot-native/usr/lib/aarch64-poky-linux/gcc/aarch64-poky-linux/7.2.1/include/stdint.h:9:16:
fatal error: stdint.h: No such file or directory
 # include_next <stdint.h>
                ^~~~~~~~~~
compilation terminated.


Thanks

On Fri, May 3, 2019 at 5:19 PM Wei Liu <wei.liu2@citrix.com> wrote:
>
> On Fri, May 03, 2019 at 03:16:52PM +0100, Julien Grall wrote:
> > > > diff --git a/xen/common/libfdt/Makefile b/xen/common/libfdt/Makefile
> > > > index d81f54b6b8..c075bbf546 100644
> > > > --- a/xen/common/libfdt/Makefile
> > > > +++ b/xen/common/libfdt/Makefile
> > > > @@ -3,6 +3,7 @@ include Makefile.libfdt
> > > >   SECTIONS := text data $(SPECIAL_DATA_SECTIONS)
> > > >
> > > >   obj-y += libfdt.o
> > > > +nocov-y += libfdt.o
> > > >
> > > >   CFLAGS += -I$(BASEDIR)/include/xen/libfdt/
> > > >
> > > > While looking at the code, I noticed libelf is also built with coverage but
> > > > in .init section. So I would expect the same error on x86, did you try
> > > > "xencov reset" on x86?
> > >
> > > I did. It worked. Though at this point I'm not sure why it worked. :-/
> >
> > I think I know why, only the sections .text and .data are prefixed with
> > .init. In the case of libelf, none of the GCOV symbols seems to be located
> > in .data.
> >
> > For libfdt, some of them are located in .data (renamed to .init.data). Hence
> > the difference in behavior.
> >
>
> Thanks for the analysis.
>
> > We should probably fixed the two libraries as this is quite fragile for
> > libelf as well.
>
> Sounds good to me.
>
> Wei.
>
> >
> > Cheers,
> >
> > --
> > Julien Grall
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xenproject.org
> > https://lists.xenproject.org/mailman/listinfo/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: Xen GCC coverage ARM64 testing - Unexpected Trap: Data Abort

[Julien Grall]

On 5/13/19 9:18 AM, Viktor Mitin wrote:
> Hi Julien,

Hi,

> Please be aware that the patch you proposed (+nocov-y += libfdt.o)
> failed to build with the next error (xen 4.12):

My patch is based on 4.13, although should work on Xen 4.12. But...

> 
> aarch64-poky-linux-gcc   -DBUILD_ID -fno-strict-aliasing -std=gnu99
> -Wall -Wstrict-prototypes -Wdeclaration-after-statement
> -Wno-unused-but-set-variable -Wno-unused-local-typedefs   -O2
> -fomit-frame-pointer
> -D__XEN_INTERFACE_VERSION__=__XEN_LATEST_INTERFACE_VERSION__ -MMD -MF
> .handlereg.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE   -Werror
> -Wmissing-prototypes -I./include
> -I/home/c/w/rcar_h3_ubuntu1604_yocto/build/tmp/work/aarch64-poky-linux/xen/4.12.0.0+gitAUTOINC+fd2a34c965-r0/git/tools/libs/toolcore/../../../tools/include
>   -c -o handlereg.o handlereg.c

... this looks like a tool building error when I only touch the 
hypervisor part. Are you certain this is my patch and not another error 
in Xen 4.12 (or any patch you have on top)?

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Xen GCC coverage ARM64 testing - Unexpected Trap: Data Abort

[Julien Grall]

On 5/13/19 9:18 AM, Viktor Mitin wrote:
> Hi Julien,

Hi,

> Please be aware that the patch you proposed (+nocov-y += libfdt.o)
> failed to build with the next error (xen 4.12):

My patch is based on 4.13, although should work on Xen 4.12. But...

> 
> aarch64-poky-linux-gcc   -DBUILD_ID -fno-strict-aliasing -std=gnu99
> -Wall -Wstrict-prototypes -Wdeclaration-after-statement
> -Wno-unused-but-set-variable -Wno-unused-local-typedefs   -O2
> -fomit-frame-pointer
> -D__XEN_INTERFACE_VERSION__=__XEN_LATEST_INTERFACE_VERSION__ -MMD -MF
> .handlereg.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE   -Werror
> -Wmissing-prototypes -I./include
> -I/home/c/w/rcar_h3_ubuntu1604_yocto/build/tmp/work/aarch64-poky-linux/xen/4.12.0.0+gitAUTOINC+fd2a34c965-r0/git/tools/libs/toolcore/../../../tools/include
>   -c -o handlereg.o handlereg.c

... this looks like a tool building error when I only touch the 
hypervisor part. Are you certain this is my patch and not another error 
in Xen 4.12 (or any patch you have on top)?

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: Xen GCC coverage ARM64 testing - Unexpected Trap: Data Abort

[Viktor Mitin]

> > aarch64-poky-linux-gcc   -DBUILD_ID -fno-strict-aliasing -std=gnu99
> > -Wall -Wstrict-prototypes -Wdeclaration-after-statement
> > -Wno-unused-but-set-variable -Wno-unused-local-typedefs   -O2
> > -fomit-frame-pointer
> > -D__XEN_INTERFACE_VERSION__=__XEN_LATEST_INTERFACE_VERSION__ -MMD -MF
> > .handlereg.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE   -Werror
> > -Wmissing-prototypes -I./include
> > -I/home/c/w/rcar_h3_ubuntu1604_yocto/build/tmp/work/aarch64-poky-linux/xen/4.12.0.0+gitAUTOINC+fd2a34c965-r0/git/tools/libs/toolcore/../../../tools/include
> >   -c -o handlereg.o handlereg.c
>
> ... this looks like a tool building error when I only touch the
> hypervisor part. Are you certain this is my patch and not another error
> in Xen 4.12 (or any patch you have on top)?

Julien, you are right, it was local environment build issue (sorry for that).
Xen GCC coverage feature works well with Aarch64 with this patch.
Checked both commands, xencov read and xencov reset - both work well
(no crashes anymore).

Please also note that use case mentioned in Xen documentation
(xencov_split) is also ok with generated coverage.dat input:
xen.git/xen$ ssh root@host xencov read > coverage.dat
xen.git/xen$ ../tools/xencov_split coverage.dat --output-dir=/
xen.git/xen$ geninfo . -o cov.info
xen.git/xen$ genhtml cov.info -o cov/
xen.git/xen$ $BROWSER cov/index.html

--------
Minor observation about coverage build procedure. Documentation states:
"To build with coverage support, enable CONFIG_COVERAGE in Kconfig."
However, to build it properly, it needs to enable coverage feature in
two places - main xen make command line and hypervisor .config file.
Is it expected way to build xen with coverage feature? If yes,
probably we should improve (or at least document) it some day...

Thanks

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Xen GCC coverage ARM64 testing - Unexpected Trap: Data Abort

[Viktor Mitin]

> > aarch64-poky-linux-gcc   -DBUILD_ID -fno-strict-aliasing -std=gnu99
> > -Wall -Wstrict-prototypes -Wdeclaration-after-statement
> > -Wno-unused-but-set-variable -Wno-unused-local-typedefs   -O2
> > -fomit-frame-pointer
> > -D__XEN_INTERFACE_VERSION__=__XEN_LATEST_INTERFACE_VERSION__ -MMD -MF
> > .handlereg.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE   -Werror
> > -Wmissing-prototypes -I./include
> > -I/home/c/w/rcar_h3_ubuntu1604_yocto/build/tmp/work/aarch64-poky-linux/xen/4.12.0.0+gitAUTOINC+fd2a34c965-r0/git/tools/libs/toolcore/../../../tools/include
> >   -c -o handlereg.o handlereg.c
>
> ... this looks like a tool building error when I only touch the
> hypervisor part. Are you certain this is my patch and not another error
> in Xen 4.12 (or any patch you have on top)?

Julien, you are right, it was local environment build issue (sorry for that).
Xen GCC coverage feature works well with Aarch64 with this patch.
Checked both commands, xencov read and xencov reset - both work well
(no crashes anymore).

Please also note that use case mentioned in Xen documentation
(xencov_split) is also ok with generated coverage.dat input:
xen.git/xen$ ssh root@host xencov read > coverage.dat
xen.git/xen$ ../tools/xencov_split coverage.dat --output-dir=/
xen.git/xen$ geninfo . -o cov.info
xen.git/xen$ genhtml cov.info -o cov/
xen.git/xen$ $BROWSER cov/index.html

--------
Minor observation about coverage build procedure. Documentation states:
"To build with coverage support, enable CONFIG_COVERAGE in Kconfig."
However, to build it properly, it needs to enable coverage feature in
two places - main xen make command line and hypervisor .config file.
Is it expected way to build xen with coverage feature? If yes,
probably we should improve (or at least document) it some day...

Thanks

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: Xen GCC coverage ARM64 testing - Unexpected Trap: Data Abort

[Julien Grall]

On 5/13/19 11:29 AM, Viktor Mitin wrote:
>>> aarch64-poky-linux-gcc   -DBUILD_ID -fno-strict-aliasing -std=gnu99
>>> -Wall -Wstrict-prototypes -Wdeclaration-after-statement
>>> -Wno-unused-but-set-variable -Wno-unused-local-typedefs   -O2
>>> -fomit-frame-pointer
>>> -D__XEN_INTERFACE_VERSION__=__XEN_LATEST_INTERFACE_VERSION__ -MMD -MF
>>> .handlereg.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE   -Werror
>>> -Wmissing-prototypes -I./include
>>> -I/home/c/w/rcar_h3_ubuntu1604_yocto/build/tmp/work/aarch64-poky-linux/xen/4.12.0.0+gitAUTOINC+fd2a34c965-r0/git/tools/libs/toolcore/../../../tools/include
>>>    -c -o handlereg.o handlereg.c
>>
>> ... this looks like a tool building error when I only touch the
>> hypervisor part. Are you certain this is my patch and not another error
>> in Xen 4.12 (or any patch you have on top)?
> 
> Julien, you are right, it was local environment build issue (sorry for that).
> Xen GCC coverage feature works well with Aarch64 with this patch.
> Checked both commands, xencov read and xencov reset - both work well
> (no crashes anymore).
> 
> Please also note that use case mentioned in Xen documentation
> (xencov_split) is also ok with generated coverage.dat input:
> xen.git/xen$ ssh root@host xencov read > coverage.dat
> xen.git/xen$ ../tools/xencov_split coverage.dat --output-dir=/
> xen.git/xen$ geninfo . -o cov.info
> xen.git/xen$ genhtml cov.info -o cov/
> xen.git/xen$ $BROWSER cov/index.html
> 
> --------
> Minor observation about coverage build procedure. Documentation states:
> "To build with coverage support, enable CONFIG_COVERAGE in Kconfig."
> However, to build it properly, it needs to enable coverage feature in
> two places - main xen make command line and hypervisor .config file.
> Is it expected way to build xen with coverage feature? If yes,
> probably we should improve (or at least document) it some day...

What is require on the make command line?

As usual, patches are welcomed ;).

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Xen GCC coverage ARM64 testing - Unexpected Trap: Data Abort

[Julien Grall]

On 5/13/19 11:29 AM, Viktor Mitin wrote:
>>> aarch64-poky-linux-gcc   -DBUILD_ID -fno-strict-aliasing -std=gnu99
>>> -Wall -Wstrict-prototypes -Wdeclaration-after-statement
>>> -Wno-unused-but-set-variable -Wno-unused-local-typedefs   -O2
>>> -fomit-frame-pointer
>>> -D__XEN_INTERFACE_VERSION__=__XEN_LATEST_INTERFACE_VERSION__ -MMD -MF
>>> .handlereg.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE   -Werror
>>> -Wmissing-prototypes -I./include
>>> -I/home/c/w/rcar_h3_ubuntu1604_yocto/build/tmp/work/aarch64-poky-linux/xen/4.12.0.0+gitAUTOINC+fd2a34c965-r0/git/tools/libs/toolcore/../../../tools/include
>>>    -c -o handlereg.o handlereg.c
>>
>> ... this looks like a tool building error when I only touch the
>> hypervisor part. Are you certain this is my patch and not another error
>> in Xen 4.12 (or any patch you have on top)?
> 
> Julien, you are right, it was local environment build issue (sorry for that).
> Xen GCC coverage feature works well with Aarch64 with this patch.
> Checked both commands, xencov read and xencov reset - both work well
> (no crashes anymore).
> 
> Please also note that use case mentioned in Xen documentation
> (xencov_split) is also ok with generated coverage.dat input:
> xen.git/xen$ ssh root@host xencov read > coverage.dat
> xen.git/xen$ ../tools/xencov_split coverage.dat --output-dir=/
> xen.git/xen$ geninfo . -o cov.info
> xen.git/xen$ genhtml cov.info -o cov/
> xen.git/xen$ $BROWSER cov/index.html
> 
> --------
> Minor observation about coverage build procedure. Documentation states:
> "To build with coverage support, enable CONFIG_COVERAGE in Kconfig."
> However, to build it properly, it needs to enable coverage feature in
> two places - main xen make command line and hypervisor .config file.
> Is it expected way to build xen with coverage feature? If yes,
> probably we should improve (or at least document) it some day...

What is require on the make command line?

As usual, patches are welcomed ;).

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: Xen GCC coverage ARM64 testing - Unexpected Trap: Data Abort

[Wei Liu]

On Mon, May 13, 2019 at 01:29:12PM +0300, Viktor Mitin wrote:
> > > aarch64-poky-linux-gcc   -DBUILD_ID -fno-strict-aliasing -std=gnu99
> > > -Wall -Wstrict-prototypes -Wdeclaration-after-statement
> > > -Wno-unused-but-set-variable -Wno-unused-local-typedefs   -O2
> > > -fomit-frame-pointer
> > > -D__XEN_INTERFACE_VERSION__=__XEN_LATEST_INTERFACE_VERSION__ -MMD -MF
> > > .handlereg.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE   -Werror
> > > -Wmissing-prototypes -I./include
> > > -I/home/c/w/rcar_h3_ubuntu1604_yocto/build/tmp/work/aarch64-poky-linux/xen/4.12.0.0+gitAUTOINC+fd2a34c965-r0/git/tools/libs/toolcore/../../../tools/include
> > >   -c -o handlereg.o handlereg.c
> >
> > ... this looks like a tool building error when I only touch the
> > hypervisor part. Are you certain this is my patch and not another error
> > in Xen 4.12 (or any patch you have on top)?
> 
> Julien, you are right, it was local environment build issue (sorry for that).
> Xen GCC coverage feature works well with Aarch64 with this patch.
> Checked both commands, xencov read and xencov reset - both work well
> (no crashes anymore).
> 
> Please also note that use case mentioned in Xen documentation
> (xencov_split) is also ok with generated coverage.dat input:
> xen.git/xen$ ssh root@host xencov read > coverage.dat
> xen.git/xen$ ../tools/xencov_split coverage.dat --output-dir=/
> xen.git/xen$ geninfo . -o cov.info
> xen.git/xen$ genhtml cov.info -o cov/
> xen.git/xen$ $BROWSER cov/index.html
> 
> --------
> Minor observation about coverage build procedure. Documentation states:
> "To build with coverage support, enable CONFIG_COVERAGE in Kconfig."
> However, to build it properly, it needs to enable coverage feature in
> two places - main xen make command line and hypervisor .config file.
> Is it expected way to build xen with coverage feature? If yes,
> probably we should improve (or at least document) it some day...

What does your make command line look like?

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Xen GCC coverage ARM64 testing - Unexpected Trap: Data Abort

[Wei Liu]

On Mon, May 13, 2019 at 01:29:12PM +0300, Viktor Mitin wrote:
> > > aarch64-poky-linux-gcc   -DBUILD_ID -fno-strict-aliasing -std=gnu99
> > > -Wall -Wstrict-prototypes -Wdeclaration-after-statement
> > > -Wno-unused-but-set-variable -Wno-unused-local-typedefs   -O2
> > > -fomit-frame-pointer
> > > -D__XEN_INTERFACE_VERSION__=__XEN_LATEST_INTERFACE_VERSION__ -MMD -MF
> > > .handlereg.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE   -Werror
> > > -Wmissing-prototypes -I./include
> > > -I/home/c/w/rcar_h3_ubuntu1604_yocto/build/tmp/work/aarch64-poky-linux/xen/4.12.0.0+gitAUTOINC+fd2a34c965-r0/git/tools/libs/toolcore/../../../tools/include
> > >   -c -o handlereg.o handlereg.c
> >
> > ... this looks like a tool building error when I only touch the
> > hypervisor part. Are you certain this is my patch and not another error
> > in Xen 4.12 (or any patch you have on top)?
> 
> Julien, you are right, it was local environment build issue (sorry for that).
> Xen GCC coverage feature works well with Aarch64 with this patch.
> Checked both commands, xencov read and xencov reset - both work well
> (no crashes anymore).
> 
> Please also note that use case mentioned in Xen documentation
> (xencov_split) is also ok with generated coverage.dat input:
> xen.git/xen$ ssh root@host xencov read > coverage.dat
> xen.git/xen$ ../tools/xencov_split coverage.dat --output-dir=/
> xen.git/xen$ geninfo . -o cov.info
> xen.git/xen$ genhtml cov.info -o cov/
> xen.git/xen$ $BROWSER cov/index.html
> 
> --------
> Minor observation about coverage build procedure. Documentation states:
> "To build with coverage support, enable CONFIG_COVERAGE in Kconfig."
> However, to build it properly, it needs to enable coverage feature in
> two places - main xen make command line and hypervisor .config file.
> Is it expected way to build xen with coverage feature? If yes,
> probably we should improve (or at least document) it some day...

What does your make command line look like?

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: Xen GCC coverage ARM64 testing - Unexpected Trap: Data Abort

[Viktor Mitin]

Hi Wei and Julien,

Thank you for the hints provided. It is appeared that it was Yocto Xen
receipt issue and not Xen coverage feature issue.
We see that xencov* tools are built anyway, even in the case when
CONFIG_COVERAGE is not enabled in hypervisor Kconfig.
Is there a reason for this?

To summarize, there is no need to enable coverage feature in two
places, only in Kconfig, as mentioned in documentation.
It has been rechecked with Xen 4.12, and works well as expected.

---
Xen 4.13 has not been checked yet with the patch. Currently, xen 4.13
staging fails to boot due to unknown reason... it worked some days
ago.
It hangs after the next log currently:
(XEN) Failed to bring up CPU 7 (error -5)
(XEN) Brought up 4 CPUs
(XEN) P2M: 44-bit IPA with 44-bit PA and 8-bit VMID
(XEN) P2M: 4 levels with order-0 root, VTCR 0x80043594
(XEN) I/O virtualisation disabled
(XEN) build-id: f4ea2c93ff09225beed05f629a3813b4e31c420d
(XEN) alternatives: Patching with alt table 0000000000343d58 -> 0000000000344418
---

Julien, are you going to integrate the patch?

Thanks

On Mon, May 13, 2019 at 1:43 PM Wei Liu <wei.liu2@citrix.com> wrote:
>
> On Mon, May 13, 2019 at 01:29:12PM +0300, Viktor Mitin wrote:
> > > > aarch64-poky-linux-gcc   -DBUILD_ID -fno-strict-aliasing -std=gnu99
> > > > -Wall -Wstrict-prototypes -Wdeclaration-after-statement
> > > > -Wno-unused-but-set-variable -Wno-unused-local-typedefs   -O2
> > > > -fomit-frame-pointer
> > > > -D__XEN_INTERFACE_VERSION__=__XEN_LATEST_INTERFACE_VERSION__ -MMD -MF
> > > > .handlereg.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE   -Werror
> > > > -Wmissing-prototypes -I./include
> > > > -I/home/c/w/rcar_h3_ubuntu1604_yocto/build/tmp/work/aarch64-poky-linux/xen/4.12.0.0+gitAUTOINC+fd2a34c965-r0/git/tools/libs/toolcore/../../../tools/include
> > > >   -c -o handlereg.o handlereg.c
> > >
> > > ... this looks like a tool building error when I only touch the
> > > hypervisor part. Are you certain this is my patch and not another error
> > > in Xen 4.12 (or any patch you have on top)?
> >
> > Julien, you are right, it was local environment build issue (sorry for that).
> > Xen GCC coverage feature works well with Aarch64 with this patch.
> > Checked both commands, xencov read and xencov reset - both work well
> > (no crashes anymore).
> >
> > Please also note that use case mentioned in Xen documentation
> > (xencov_split) is also ok with generated coverage.dat input:
> > xen.git/xen$ ssh root@host xencov read > coverage.dat
> > xen.git/xen$ ../tools/xencov_split coverage.dat --output-dir=/
> > xen.git/xen$ geninfo . -o cov.info
> > xen.git/xen$ genhtml cov.info -o cov/
> > xen.git/xen$ $BROWSER cov/index.html
> >
> > --------
> > Minor observation about coverage build procedure. Documentation states:
> > "To build with coverage support, enable CONFIG_COVERAGE in Kconfig."
> > However, to build it properly, it needs to enable coverage feature in
> > two places - main xen make command line and hypervisor .config file.
> > Is it expected way to build xen with coverage feature? If yes,
> > probably we should improve (or at least document) it some day...
>
> What does your make command line look like?
>
> Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Xen GCC coverage ARM64 testing - Unexpected Trap: Data Abort

[Viktor Mitin]

Hi Wei and Julien,

Thank you for the hints provided. It is appeared that it was Yocto Xen
receipt issue and not Xen coverage feature issue.
We see that xencov* tools are built anyway, even in the case when
CONFIG_COVERAGE is not enabled in hypervisor Kconfig.
Is there a reason for this?

To summarize, there is no need to enable coverage feature in two
places, only in Kconfig, as mentioned in documentation.
It has been rechecked with Xen 4.12, and works well as expected.

---
Xen 4.13 has not been checked yet with the patch. Currently, xen 4.13
staging fails to boot due to unknown reason... it worked some days
ago.
It hangs after the next log currently:
(XEN) Failed to bring up CPU 7 (error -5)
(XEN) Brought up 4 CPUs
(XEN) P2M: 44-bit IPA with 44-bit PA and 8-bit VMID
(XEN) P2M: 4 levels with order-0 root, VTCR 0x80043594
(XEN) I/O virtualisation disabled
(XEN) build-id: f4ea2c93ff09225beed05f629a3813b4e31c420d
(XEN) alternatives: Patching with alt table 0000000000343d58 -> 0000000000344418
---

Julien, are you going to integrate the patch?

Thanks

On Mon, May 13, 2019 at 1:43 PM Wei Liu <wei.liu2@citrix.com> wrote:
>
> On Mon, May 13, 2019 at 01:29:12PM +0300, Viktor Mitin wrote:
> > > > aarch64-poky-linux-gcc   -DBUILD_ID -fno-strict-aliasing -std=gnu99
> > > > -Wall -Wstrict-prototypes -Wdeclaration-after-statement
> > > > -Wno-unused-but-set-variable -Wno-unused-local-typedefs   -O2
> > > > -fomit-frame-pointer
> > > > -D__XEN_INTERFACE_VERSION__=__XEN_LATEST_INTERFACE_VERSION__ -MMD -MF
> > > > .handlereg.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE   -Werror
> > > > -Wmissing-prototypes -I./include
> > > > -I/home/c/w/rcar_h3_ubuntu1604_yocto/build/tmp/work/aarch64-poky-linux/xen/4.12.0.0+gitAUTOINC+fd2a34c965-r0/git/tools/libs/toolcore/../../../tools/include
> > > >   -c -o handlereg.o handlereg.c
> > >
> > > ... this looks like a tool building error when I only touch the
> > > hypervisor part. Are you certain this is my patch and not another error
> > > in Xen 4.12 (or any patch you have on top)?
> >
> > Julien, you are right, it was local environment build issue (sorry for that).
> > Xen GCC coverage feature works well with Aarch64 with this patch.
> > Checked both commands, xencov read and xencov reset - both work well
> > (no crashes anymore).
> >
> > Please also note that use case mentioned in Xen documentation
> > (xencov_split) is also ok with generated coverage.dat input:
> > xen.git/xen$ ssh root@host xencov read > coverage.dat
> > xen.git/xen$ ../tools/xencov_split coverage.dat --output-dir=/
> > xen.git/xen$ geninfo . -o cov.info
> > xen.git/xen$ genhtml cov.info -o cov/
> > xen.git/xen$ $BROWSER cov/index.html
> >
> > --------
> > Minor observation about coverage build procedure. Documentation states:
> > "To build with coverage support, enable CONFIG_COVERAGE in Kconfig."
> > However, to build it properly, it needs to enable coverage feature in
> > two places - main xen make command line and hypervisor .config file.
> > Is it expected way to build xen with coverage feature? If yes,
> > probably we should improve (or at least document) it some day...
>
> What does your make command line look like?
>
> Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: Xen GCC coverage ARM64 testing - Unexpected Trap: Data Abort

[Julien Grall]

Hi,

On 5/13/19 3:39 PM, Viktor Mitin wrote:
> Hi Wei and Julien,
> ---
> Xen 4.13 has not been checked yet with the patch. Currently, xen 4.13
> staging fails to boot due to unknown reason... it worked some days
> ago.
> It hangs after the next log currently:
> (XEN) Failed to bring up CPU 7 (error -5)
> (XEN) Brought up 4 CPUs
> (XEN) P2M: 44-bit IPA with 44-bit PA and 8-bit VMID
> (XEN) P2M: 4 levels with order-0 root, VTCR 0x80043594
> (XEN) I/O virtualisation disabled
> (XEN) build-id: f4ea2c93ff09225beed05f629a3813b4e31c420d
> (XEN) alternatives: Patching with alt table 0000000000343d58 -> 0000000000344418

Which commit are you using? Do you remember which one worked? If so, can 
you bisect it?

> ---
> 
> Julien, are you going to integrate the patch?

For that someone needs to send a patch so it can be reviewed. I was 
hoping you could do that as the reporter of the problem.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Xen GCC coverage ARM64 testing - Unexpected Trap: Data Abort

[Julien Grall]

Hi,

On 5/13/19 3:39 PM, Viktor Mitin wrote:
> Hi Wei and Julien,
> ---
> Xen 4.13 has not been checked yet with the patch. Currently, xen 4.13
> staging fails to boot due to unknown reason... it worked some days
> ago.
> It hangs after the next log currently:
> (XEN) Failed to bring up CPU 7 (error -5)
> (XEN) Brought up 4 CPUs
> (XEN) P2M: 44-bit IPA with 44-bit PA and 8-bit VMID
> (XEN) P2M: 4 levels with order-0 root, VTCR 0x80043594
> (XEN) I/O virtualisation disabled
> (XEN) build-id: f4ea2c93ff09225beed05f629a3813b4e31c420d
> (XEN) alternatives: Patching with alt table 0000000000343d58 -> 0000000000344418

Which commit are you using? Do you remember which one worked? If so, can 
you bisect it?

> ---
> 
> Julien, are you going to integrate the patch?

For that someone needs to send a patch so it can be reviewed. I was 
hoping you could do that as the reporter of the problem.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: Xen GCC coverage ARM64 testing - Unexpected Trap: Data Abort

[Wei Liu]

On Mon, May 13, 2019 at 05:39:55PM +0300, Viktor Mitin wrote:
> Hi Wei and Julien,
> 
> Thank you for the hints provided. It is appeared that it was Yocto Xen
> receipt issue and not Xen coverage feature issue.
> We see that xencov* tools are built anyway, even in the case when
> CONFIG_COVERAGE is not enabled in hypervisor Kconfig.
> Is there a reason for this?

Though the tools and hypervisor live in one repository, their build
systems aren't really that connected.

It wouldn't hurt to build the xencov tool in any case.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Xen GCC coverage ARM64 testing - Unexpected Trap: Data Abort

[Wei Liu]

On Mon, May 13, 2019 at 05:39:55PM +0300, Viktor Mitin wrote:
> Hi Wei and Julien,
> 
> Thank you for the hints provided. It is appeared that it was Yocto Xen
> receipt issue and not Xen coverage feature issue.
> We see that xencov* tools are built anyway, even in the case when
> CONFIG_COVERAGE is not enabled in hypervisor Kconfig.
> Is there a reason for this?

Though the tools and hypervisor live in one repository, their build
systems aren't really that connected.

It wouldn't hurt to build the xencov tool in any case.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel