-
Notifications
You must be signed in to change notification settings - Fork 346
target/riscv: fix riscv_mmu behaviour #1256
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
base: riscv
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM (reviewed internally).
@JanMatCodasip, @MarekVCodasip, could you please take a look? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Thank you!
if (!riscv_virt2phys_mode_is_sw(target)) | ||
return ERROR_OK; | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Access memory would fail while virt2phys_mode is hw.
if (!riscv_virt2phys_mode_is_sw(target)) | |
return ERROR_OK; | |
if (riscv_virt2phys_mode_is_hw(target)) | |
return ERROR_OK; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With this check virt2phys_mode
would return incorrect value: virtual address instead of physical
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Access memory would fail without this check virt2phys_mode
while virt2phys_mode is hw. It is correct to return a virtual address while virt2phys_mode is hw. Address translation should be done by hardware when set dcsr.mprven
, I have tested it. When virt2phys_mode is hw, the virt2phys command returns the physical address, at least the current modification is incorrect, and both the virt2phys command and memory access will report errors.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, I've mistaken. I meant that virt2phys
would return incorrect value
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I understand you now. You are right, here we have double translation. But I think it has to be fixed in riscv_rw_memory
function. Something like:
if (riscv_virt2phys_mode_is_hw(target))
return r->access_memory(target, args);
before translation.
Sorry for the mess. This change was a part of #1241. Looks like I have extracted this part incorrectly
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When virt2phys_mode is hw, the virt2phys command still report errors. Translate page table accesses failed due to setting dcsr.mprven
. I think maybe it could be fixed in riscv_virt2phys
function like this:
RISCV_INFO(r);
int mode = r->virt2phys_mode;
if (riscv_virt2phys_mode_is_hw(target))
r->virt2phys_mode = RISCV_VIRT2PHYS_MODE_SW;
int result = riscv_address_translate(target,
satp_info, get_field(satp_value, RISCV_SATP_PPN(xlen)),
NULL, 0,
virtual, physical);
r->virt2phys_mode = mode;
return result;
Fixed riscv_mmu behaviour: buggy check was removed. As a result virt2phys command behaviour was fixed: now it returns translated address even while virt2phys_mode is off. Change-Id: Ie2e6d1057024ab794038d5ed3662ef49a4d71e70 Signed-off-by: Farid Khaydari <[email protected]>
Fixed riscv_mmu behaviour: buggy check was removed.
As a result virt2phys command behaviour was fixed: now it
returns translated address even while virt2phys_mode is off.
Change-Id: Ie2e6d1057024ab794038d5ed3662ef49a4d71e70