Undefined TLBI instruction for armv8 processor in gem5

up vote
1
down vote

favorite

I encountered a gem5 error while running gem5 fs simulation for aarch64 in bare metal mode. Especially, when my custom boot code tried to invalidate TLB with an assembly instruction tlbi ALLE3, the simulator reported the following message:

system.cpu T0 : @core0+72    :   msr   tlbi_alle3, xzr    : IntAlu :

Undefined Instruction: Invoking Fault (AArch64 target EL) : Undefined Instruction cpsr:0x3c5 PC:0x2186c elr:0x2186c newVec: 0xa00

Also, I tested with "tlbi ALLE1" but it ended up with the same error. For your reference, I configured a cpu type with TimingSimpleCPU. Based on the message, the passed tlbi instruction seems to be unimplemented in ARM64 processor model. However, since I know that gem5 successfully boots Linux for aarch64 in fs mode, I am wondering how the case could handle the tlbi instruction. In other words, if the tlbi instruction is really unimplemented instruction in gem5, I think that booting Linux should also have run into the same error. Can I know if anyone has experienced the undefined instruction fault of tlbi in gem5?
Thanks for your answer/comment in advance.

Update1: Further investigation showed that tlbi VMALLE3 did not cause any error, while tlbi ALLE3 instruction caused an undefined instruction fault.

edited Nov 13 at 22:43

asked Nov 12 at 21:38

Cherry

add a comment |

up vote
1
down vote

favorite

system.cpu T0 : @core0+72    :   msr   tlbi_alle3, xzr    : IntAlu :

Undefined Instruction: Invoking Fault (AArch64 target EL) : Undefined Instruction cpsr:0x3c5 PC:0x2186c elr:0x2186c newVec: 0xa00

Update1: Further investigation showed that tlbi VMALLE3 did not cause any error, while tlbi ALLE3 instruction caused an undefined instruction fault.

edited Nov 13 at 22:43

asked Nov 12 at 21:38

Cherry

add a comment |

up vote
1
down vote

favorite

system.cpu T0 : @core0+72    :   msr   tlbi_alle3, xzr    : IntAlu :

Undefined Instruction: Invoking Fault (AArch64 target EL) : Undefined Instruction cpsr:0x3c5 PC:0x2186c elr:0x2186c newVec: 0xa00

Update1: Further investigation showed that tlbi VMALLE3 did not cause any error, while tlbi ALLE3 instruction caused an undefined instruction fault.

edited Nov 13 at 22:43

asked Nov 12 at 21:38

Cherry

system.cpu T0 : @core0+72    :   msr   tlbi_alle3, xzr    : IntAlu :

Undefined Instruction: Invoking Fault (AArch64 target EL) : Undefined Instruction cpsr:0x3c5 PC:0x2186c elr:0x2186c newVec: 0xa00

Update1: Further investigation showed that tlbi VMALLE3 did not cause any error, while tlbi ALLE3 instruction caused an undefined instruction fault.

arm64 bare-metal gem5

edited Nov 13 at 22:43

asked Nov 12 at 21:38

Cherry

edited Nov 13 at 22:43

asked Nov 12 at 21:38

Cherry

edited Nov 13 at 22:43

asked Nov 12 at 21:38

Cherry

asked Nov 12 at 21:38

Cherry

asked Nov 12 at 21:38

Cherry

add a comment |

1 Answer
1

active

oldest

votes

up vote
0
down vote

The Linux kernel only exercises a subset of all ARM functionality.

For example, Linux v4.18 ARMv7 broke because it started using CSDB, and so we just marked that instruction as ignored for now: https://github.com/gem5/gem5/commit/33b311d8d8b8d527d500d62a35b50be63e41b556 which just emits a warning instead, since that instruction is implementation defined and could be a NOP.

Notably, there are several ARMv8.x instructions which are not yet implemented.

So I recommend the following:

grep the .isa files under src/arch/arm/isa/ and search for the exact tlbi encoding that you are using.

Those files are responsible for the instruction decoding, so if an instruction is implemented, that is where you have to look.

There are already hits under tlbi, but make sure that your exact instruction bytes are going to the right place.

GDB step debug gem5 if necessary, and remember that there might be a decoding bug and that the bytes actually should be another instruction.

Actually do a Linux kernel boot trace with --debug-flags=Exec and see if it contains the mentioned instruction.

Provide a line of assembly that reproduces the problem, and a GNU GAS version used to assemble it so that others can reproduce.

If you find that there is a missing encoding, and are able to implement it fully, or if it is a implementation defined NOP like CSDB just ignore it with a warning, send a patch on Gerrit and CC me.

edited Nov 13 at 7:06

answered Nov 13 at 6:56

Ciro Santilli

52214

Thanks for your answer. As suggested, I grepped .isa files for tlbi instruction but found no match. The TLBI instruction was converted to MSR instruction by GAS(Linaro 2014.11-3-git 2.24.0.20141017). Therefore, I searched all files for TLBI, and found matches in miscregs.[cc/hh], isa.cc, and insts/misc64.cc. I am trying to understand why access to this tlbi_alle3 misc register caused an undefined instruction fault. BTW, I found that a remote gdb connection to gem5's aarch64 simulation instance failed; "Remote 'g' packet reply is too long". Is there any fix for this?
– Cherry
Nov 13 at 20:29

@Cherry GDB problem previously reported at: mail-archive.com/gem5-users@gem5.org/msg15243.html fix should be pushed soon. I don't know much about tlbi_alle3, I think your best bet is to GDB step debug gem5 to find it out, I believe this one should not be hard to figure out. If you get stuck at some point of the debugging process, try to ping the mailing list as well.
– Ciro Santilli
Nov 14 at 10:06

Thanks. The GDB problem seems to date back last Spring. Hope the fix will get merged into master soon.
– Cherry
Nov 15 at 22:14

@Cherry this is the patchset: gem5-review.googlesource.com/c/public/gem5/+/14498
– Ciro Santilli
Nov 22 at 11:58

add a comment |

Your Answer

StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});

}
});

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53270477%2fundefined-tlbi-instruction-for-armv8-processor-in-gem5%23new-answer', 'question_page');
}
);

Post as a guest

Name

Required, but never shown

1 Answer
1

active

oldest

votes

1 Answer
1

active

oldest

votes

up vote
0
down vote

The Linux kernel only exercises a subset of all ARM functionality.

Notably, there are several ARMv8.x instructions which are not yet implemented.

So I recommend the following:

grep the .isa files under src/arch/arm/isa/ and search for the exact tlbi encoding that you are using.

Those files are responsible for the instruction decoding, so if an instruction is implemented, that is where you have to look.

There are already hits under tlbi, but make sure that your exact instruction bytes are going to the right place.

GDB step debug gem5 if necessary, and remember that there might be a decoding bug and that the bytes actually should be another instruction.

Actually do a Linux kernel boot trace with --debug-flags=Exec and see if it contains the mentioned instruction.

Provide a line of assembly that reproduces the problem, and a GNU GAS version used to assemble it so that others can reproduce.

If you find that there is a missing encoding, and are able to implement it fully, or if it is a implementation defined NOP like CSDB just ignore it with a warning, send a patch on Gerrit and CC me.

edited Nov 13 at 7:06

answered Nov 13 at 6:56

Ciro Santilli

52214

Thanks for your answer. As suggested, I grepped .isa files for tlbi instruction but found no match. The TLBI instruction was converted to MSR instruction by GAS(Linaro 2014.11-3-git 2.24.0.20141017). Therefore, I searched all files for TLBI, and found matches in miscregs.[cc/hh], isa.cc, and insts/misc64.cc. I am trying to understand why access to this tlbi_alle3 misc register caused an undefined instruction fault. BTW, I found that a remote gdb connection to gem5's aarch64 simulation instance failed; "Remote 'g' packet reply is too long". Is there any fix for this?
– Cherry
Nov 13 at 20:29

@Cherry GDB problem previously reported at: mail-archive.com/gem5-users@gem5.org/msg15243.html fix should be pushed soon. I don't know much about tlbi_alle3, I think your best bet is to GDB step debug gem5 to find it out, I believe this one should not be hard to figure out. If you get stuck at some point of the debugging process, try to ping the mailing list as well.
– Ciro Santilli
Nov 14 at 10:06

Thanks. The GDB problem seems to date back last Spring. Hope the fix will get merged into master soon.
– Cherry
Nov 15 at 22:14

@Cherry this is the patchset: gem5-review.googlesource.com/c/public/gem5/+/14498
– Ciro Santilli
Nov 22 at 11:58

add a comment |

up vote
0
down vote

The Linux kernel only exercises a subset of all ARM functionality.

Notably, there are several ARMv8.x instructions which are not yet implemented.

So I recommend the following:

grep the .isa files under src/arch/arm/isa/ and search for the exact tlbi encoding that you are using.

Those files are responsible for the instruction decoding, so if an instruction is implemented, that is where you have to look.

There are already hits under tlbi, but make sure that your exact instruction bytes are going to the right place.

GDB step debug gem5 if necessary, and remember that there might be a decoding bug and that the bytes actually should be another instruction.

Actually do a Linux kernel boot trace with --debug-flags=Exec and see if it contains the mentioned instruction.

Provide a line of assembly that reproduces the problem, and a GNU GAS version used to assemble it so that others can reproduce.

If you find that there is a missing encoding, and are able to implement it fully, or if it is a implementation defined NOP like CSDB just ignore it with a warning, send a patch on Gerrit and CC me.

edited Nov 13 at 7:06

answered Nov 13 at 6:56

Ciro Santilli

52214

Thanks for your answer. As suggested, I grepped .isa files for tlbi instruction but found no match. The TLBI instruction was converted to MSR instruction by GAS(Linaro 2014.11-3-git 2.24.0.20141017). Therefore, I searched all files for TLBI, and found matches in miscregs.[cc/hh], isa.cc, and insts/misc64.cc. I am trying to understand why access to this tlbi_alle3 misc register caused an undefined instruction fault. BTW, I found that a remote gdb connection to gem5's aarch64 simulation instance failed; "Remote 'g' packet reply is too long". Is there any fix for this?
– Cherry
Nov 13 at 20:29

@Cherry GDB problem previously reported at: mail-archive.com/gem5-users@gem5.org/msg15243.html fix should be pushed soon. I don't know much about tlbi_alle3, I think your best bet is to GDB step debug gem5 to find it out, I believe this one should not be hard to figure out. If you get stuck at some point of the debugging process, try to ping the mailing list as well.
– Ciro Santilli
Nov 14 at 10:06

Thanks. The GDB problem seems to date back last Spring. Hope the fix will get merged into master soon.
– Cherry
Nov 15 at 22:14

@Cherry this is the patchset: gem5-review.googlesource.com/c/public/gem5/+/14498
– Ciro Santilli
Nov 22 at 11:58

add a comment |

up vote
0
down vote

The Linux kernel only exercises a subset of all ARM functionality.

Notably, there are several ARMv8.x instructions which are not yet implemented.

So I recommend the following:

grep the .isa files under src/arch/arm/isa/ and search for the exact tlbi encoding that you are using.

Those files are responsible for the instruction decoding, so if an instruction is implemented, that is where you have to look.

There are already hits under tlbi, but make sure that your exact instruction bytes are going to the right place.

GDB step debug gem5 if necessary, and remember that there might be a decoding bug and that the bytes actually should be another instruction.

Actually do a Linux kernel boot trace with --debug-flags=Exec and see if it contains the mentioned instruction.

Provide a line of assembly that reproduces the problem, and a GNU GAS version used to assemble it so that others can reproduce.

If you find that there is a missing encoding, and are able to implement it fully, or if it is a implementation defined NOP like CSDB just ignore it with a warning, send a patch on Gerrit and CC me.

edited Nov 13 at 7:06

answered Nov 13 at 6:56

Ciro Santilli

52214

The Linux kernel only exercises a subset of all ARM functionality.

Notably, there are several ARMv8.x instructions which are not yet implemented.

So I recommend the following:

grep the .isa files under src/arch/arm/isa/ and search for the exact tlbi encoding that you are using.

Those files are responsible for the instruction decoding, so if an instruction is implemented, that is where you have to look.

There are already hits under tlbi, but make sure that your exact instruction bytes are going to the right place.

GDB step debug gem5 if necessary, and remember that there might be a decoding bug and that the bytes actually should be another instruction.

Actually do a Linux kernel boot trace with --debug-flags=Exec and see if it contains the mentioned instruction.

Provide a line of assembly that reproduces the problem, and a GNU GAS version used to assemble it so that others can reproduce.

If you find that there is a missing encoding, and are able to implement it fully, or if it is a implementation defined NOP like CSDB just ignore it with a warning, send a patch on Gerrit and CC me.

edited Nov 13 at 7:06

answered Nov 13 at 6:56

Ciro Santilli

52214

edited Nov 13 at 7:06

answered Nov 13 at 6:56

Ciro Santilli

52214

answered Nov 13 at 6:56

Ciro Santilli

52214

answered Nov 13 at 6:56

Ciro Santilli

52214

Thanks for your answer. As suggested, I grepped .isa files for tlbi instruction but found no match. The TLBI instruction was converted to MSR instruction by GAS(Linaro 2014.11-3-git 2.24.0.20141017). Therefore, I searched all files for TLBI, and found matches in miscregs.[cc/hh], isa.cc, and insts/misc64.cc. I am trying to understand why access to this tlbi_alle3 misc register caused an undefined instruction fault. BTW, I found that a remote gdb connection to gem5's aarch64 simulation instance failed; "Remote 'g' packet reply is too long". Is there any fix for this?
– Cherry
Nov 13 at 20:29

@Cherry GDB problem previously reported at: mail-archive.com/gem5-users@gem5.org/msg15243.html fix should be pushed soon. I don't know much about tlbi_alle3, I think your best bet is to GDB step debug gem5 to find it out, I believe this one should not be hard to figure out. If you get stuck at some point of the debugging process, try to ping the mailing list as well.
– Ciro Santilli
Nov 14 at 10:06

Thanks. The GDB problem seems to date back last Spring. Hope the fix will get merged into master soon.
– Cherry
Nov 15 at 22:14

@Cherry this is the patchset: gem5-review.googlesource.com/c/public/gem5/+/14498
– Ciro Santilli
Nov 22 at 11:58

add a comment |

Thanks for your answer. As suggested, I grepped .isa files for tlbi instruction but found no match. The TLBI instruction was converted to MSR instruction by GAS(Linaro 2014.11-3-git 2.24.0.20141017). Therefore, I searched all files for TLBI, and found matches in miscregs.[cc/hh], isa.cc, and insts/misc64.cc. I am trying to understand why access to this tlbi_alle3 misc register caused an undefined instruction fault. BTW, I found that a remote gdb connection to gem5's aarch64 simulation instance failed; "Remote 'g' packet reply is too long". Is there any fix for this?
– Cherry
Nov 13 at 20:29

@Cherry GDB problem previously reported at: mail-archive.com/gem5-users@gem5.org/msg15243.html fix should be pushed soon. I don't know much about tlbi_alle3, I think your best bet is to GDB step debug gem5 to find it out, I believe this one should not be hard to figure out. If you get stuck at some point of the debugging process, try to ping the mailing list as well.
– Ciro Santilli
Nov 14 at 10:06

Thanks. The GDB problem seems to date back last Spring. Hope the fix will get merged into master soon.
– Cherry
Nov 15 at 22:14

@Cherry this is the patchset: gem5-review.googlesource.com/c/public/gem5/+/14498
– Ciro Santilli
Nov 22 at 11:58

Thanks for your answer. As suggested, I grepped .isa files for tlbi instruction but found no match. The TLBI instruction was converted to MSR instruction by GAS(Linaro 2014.11-3-git 2.24.0.20141017). Therefore, I searched all files for TLBI, and found matches in miscregs.[cc/hh], isa.cc, and insts/misc64.cc. I am trying to understand why access to this tlbi_alle3 misc register caused an undefined instruction fault. BTW, I found that a remote gdb connection to gem5's aarch64 simulation instance failed; "Remote 'g' packet reply is too long". Is there any fix for this?
– Cherry
Nov 13 at 20:29

@Cherry GDB problem previously reported at: mail-archive.com/gem5-users@gem5.org/msg15243.html fix should be pushed soon. I don't know much about tlbi_alle3, I think your best bet is to GDB step debug gem5 to find it out, I believe this one should not be hard to figure out. If you get stuck at some point of the debugging process, try to ping the mailing list as well.
– Ciro Santilli
Nov 14 at 10:06

Thanks. The GDB problem seems to date back last Spring. Hope the fix will get merged into master soon.
– Cherry
Nov 15 at 22:14

@Cherry this is the patchset: gem5-review.googlesource.com/c/public/gem5/+/14498
– Ciro Santilli
Nov 22 at 11:58

add a comment |

draft saved

draft discarded

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Name

Required, but never shown

Name

Required, but never shown

This page is only for reference, If you need detailed information, please check here

搜尋此網誌

Cfrgtkky