Skip to content

Access memory through the scope of current privilege level #386

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.

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
merged 9 commits into from
Jul 18, 2019

Conversation

niwis
Copy link
Contributor

@niwis niwis commented Jul 5, 2019

Hi,

currently, all memory reads and writes using the program buffer are performed on physical addresses. This makes it almost impossible to debug code running in s- or u-mode with the MMU enabled.

I've considered many approaches and to me this seems to be the most reliable one.

Setting mstatus.mpp = dcsr.priv ensures that the scope is the same as in our current environment. i.e. if we are entering debug mode from m-mode, mstatus.mprv won't have any effect and the MMU remains deactivated. If, however, mstatus.mprv was already set before entering debug mode, virtualization might have been active even though we came from m-mode. Thus, don't interfere with mstatus.mpp.

Next, dcsr.mprven is set and cleared right before and after the actual access inside the program buffer. This is to ensure that the enabled MMU doesn't interfere with the functionality of debug modules that rely on memory mapped I/O with the hart.

I'm not 100% certain whether the changes are placed properly or if there should be separate functions for this, but I'm open for suggestions!

With best regards,
Nils

@timsifive
Copy link
Collaborator

This seems like it would work for a lot of use cases. The main one where it would fall down is if there's no page table entry for a given virtual address. Fixing that gets really hairy though, so it makes sense to have something like this for now.

I have a few comments so far:

  1. Please fix the style issues that caused the build to fail. OpenOCD has a strict style guide, and I'm trying to keep our fork of it clean to facilitate upstreaming.
  2. You're adding an extra command to the read/write program buffer programs. At least SiFive cores keep progbuf size to a minimum (2 instructions) so this will cause all memory access to fail. Can you add logic to only add these crc*i instructions when they'll actually be doing something?
  3. Reading/writing memory (especially a few words) already has a lot of overhead, and this adds to it. It's worth thinking about only changing mstatus when halting/just before resuming.

@niwis
Copy link
Contributor Author

niwis commented Jul 8, 2019

Thanks for the feedback!

  1. I've fixed the style issues
  2. The csr-instructions to set and clear mprven are now only added to the program buffer if
    • progbufsize is at least 4
    • and mprv is set
  3. I've reduced the average number of reads/writes. If progbufsize >= 4, the change now adds 2 register reads per memory access. If we furthermore do not come from m-mode, it adds another 2 register writes per access. Reading/writing when halting/resuming definitely sounds reasonable. However I couldn't find a short solution to prevent interferences with accesses to mstatus from other places during debug mode

Is there anything to add? And is it okay to leave out targets with a smaller program buffer for now or how would you suggest to proceed?

Copy link
Collaborator

@timsifive timsifive left a comment

Choose a reason for hiding this comment

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

Thanks for making these changes. This is looking much better. Having pondered the change some more, I have more requests, however.

I'm not comfortable with the user-visible behavior silently changing (whether addresses are interpreted as virtual/physical) depending on progbufsize which is something users have no control over, and most won't even be aware of.

We should decide which behavior we want by default, and then warn the user once per session (using LOG_INFO) if what they requested isn't possible. I'm also a bit concerned that there might be people who are unknowingly relying on the existing behavior. Can you add a configuration option that lets people pick what they want? Search riscv.c for "prefer_sba" to get an example on how to do that.

@niwis
Copy link
Contributor Author

niwis commented Jul 10, 2019

I've included your suggestions, in particular a configuration option to enable this feature. By default it is disabled now to prevent any confusion, but to me enabling it looks generally more intuitive. Perhaps changing the default behavior would be something for a release where people expect changes in the ui?

Do you have further comments or suggestions?

Copy link
Collaborator

@timsifive timsifive left a comment

Choose a reason for hiding this comment

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

Can you resolve the conflicts as well? (Sorry about that.)

@niwis
Copy link
Contributor Author

niwis commented Jul 18, 2019

Done. Anything else?

@timsifive
Copy link
Collaborator

Thanks for making this all nice and clean.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants