libsel4vm: fix number of GIC active_clr registers - #29
Conversation
4e348a7 to
f610aad
Compare
| 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) */ |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Where are we depending on these offsets?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
I'll add a comment here explaining it anyways.
There was a problem hiding this comment.
If this is virtual, all the "resX" could also be dropped
Sure, I'll do that too.
There was a problem hiding this comment.
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
| assert(!"Unable to calloc memory for VGIC"); | ||
| return -1; | ||
| } | ||
| assert(vgic); |
There was a problem hiding this comment.
Not sure is you can do that, there is no global guarantee calloc() will be successful and asserts are removed in release code. Now one could argue that it never fails in release code because this is well tested - but still, you don't know the context this is used in. So I'd prefer to keep this and have an error path here that the caller must deal with.
Another option would be making all this static, so the compiler/linker can ensure this. How much dynamism do we need there in the end?
There was a problem hiding this comment.
I agree with @axel-h, the error checking should stay as this is library and needs to allow applications to make policy choices about whether to abort on errors or do something else.
There was a problem hiding this comment.
Yes, this was my mistake, I wrongly assumed that asserts were enabled in release mode. I'll make these changes once #28 goes through.
| free(vgic_dist->priv); | ||
| return -1; | ||
| } | ||
| assert(!err); |
There was a problem hiding this comment.
We should keep the cleanup and just accept that thing might fail. It's the caller problem then to handle this.
|
I'm not sure about removing the error checking - why remove this? |
The PR #8 also works towards this, could you check if you can take over this one? |
if you already had a look there and concluded there's not much in it, then we can also close it as outdated and reference this PR as the new approach to add GICv3 support eventually. |
It's not that there's not much in it, it's that due to the code changing over time since the PR, I would rather selectively take what I need rather than take over the existing one. But if you think it's better to take over it, I can do that. |
I have not really opinion there. Cherry-picking what's useful sound like a good plan. And once there's a new PR from you we close #8 one as obsolete. |
|
Yes, I'm also happy with that approach. |
|
I think this should be put on hold until after #28 is resolved as it looks to be refactoring the same code. |
|
#28 is merged now, can you rebase this? Would be good to have the |
|
@Ivan-Velickovic: could you rebase this an resolve the conflicts, so we can merge it? |
|
@Ivan-Velickovic: could you rebase this and resolve the conflicts, so we can merge it? |
Signed-off-by: Ivan Velickovic <i.velickovic@unsw.edu.au>
f610aad to
af441e9
Compare
Ivan-Velickovic
changed the title
|
Done. Apologies for forgetting about this. |
4 participants
active_clrhas 31 registers that aren't banked, rather than 32.