Skip to content

libsel4vm: fix number of GIC active_clr registers #29

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
kent-mcleod merged 1 commit into from
Jun 15, 2022
Merged

libsel4vm: fix number of GIC active_clr registers #29

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion libsel4vm/src/arch/arm/vgic/vgic.c
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -143,7 +143,7 @@ struct gic_dist_map {
uint32_t active0[CONFIG_MAX_NUM_NODES]; /* [0x300, 0x304) */
uint32_t active[31]; /* [0x300, 0x380) */
uint32_t active_clr0[CONFIG_MAX_NUM_NODES]; /* [0x380, 0x384) */
uint32_t active_clr[32]; /* [0x384, 0x400) */
uint32_t active_clr[31]; /* [0x384, 0x400) */

@axel-h axel-h Mar 8, 2022

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems this has always been a bug then and the comments about the offsets were never right from this place on? Are we just lucky the code every worked because nobody uses this correctly?

@Ivan-Velickovic Ivan-Velickovic Mar 8, 2022

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not a bug since the only access to that field is in the distributor fault handling code, and those accesses are dependent on the offsets defined in vgicv2_defs.h, which are correct. I don't think it was ever possible to access the last element when it was length 32.

@axel-h axel-h Mar 8, 2022 •
edited
Loading

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this was a bug, because if we have 32 words here, this uses offset 0x384 - 0x404 actually, so everything after this is 4 byte off.

@Ivan-Velickovic Ivan-Velickovic Mar 8, 2022

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where are we depending on these offsets?

@axel-h axel-h Mar 8, 2022

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe I'm missing something here. Is this describing some actual hardware or is this is virtual peripheral where the actual memory layout does not matter because it only ever accesses via the filed names, so the compiler handles this properly and any memory layout could be used?

@axel-h axel-h Mar 8, 2022

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this is virtual, all the "resX" could also be dropped, because nobody needs them and they don't guarantee anything when CONFIG_MAX_NUM_NODES changes.

@Ivan-Velickovic Ivan-Velickovic Mar 8, 2022

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm implementing GICv3 right now, and was planning on adding a comment explaining why the register map is dependent on CONFIG_MAX_NUM_NODES and so the offsets aren't always correct. I think that they still have value, it's easier for me to go to the spec based on an offset commented rather than the name of the field.

@Ivan-Velickovic Ivan-Velickovic Mar 8, 2022

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll add a comment here explaining it anyways.

@Ivan-Velickovic Ivan-Velickovic Mar 8, 2022

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this is virtual, all the "resX" could also be dropped

Sure, I'll do that too.

@axel-h axel-h Mar 8, 2022

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

offsets [...] still have value, it's easier for me to go to the spec based on an offset commented rather than the name of the field.

Well, I'd argue here, that the specs [1][2] also use names, and these might be easier to search for than the number.

[1] https://developer.arm.com/documentation/ddi0471/b/programmers-model/distributor-register-summary
[2] https://developer.arm.com/documentation/ddi0516/e/programmers-model/distributor-register-summary

uint32_t priority0[CONFIG_MAX_NUM_NODES][8]; /* [0x400, 0x420) */
uint32_t priority[247]; /* [0x420, 0x7FC) */
uint32_t res3; /* 0x7FC */
Expand Down