search

riscv-admin / dev-partners

This repo is for tracking of RISC-V Development Partners Activities
3 stars 0 forks source link

Pointer Masking ACT #15

Open jjscheel opened 1 year ago

jjscheel commented 1 year ago

Technical Group

Pointer Masking TG

ratification-pkg

Pointer Masking

Technical Liaison

Martin Maas, Adam Zabrocki

Task Category

Arch Tests

Task Sub Category

Ratification Target

3Q2023

Statement of Work (SOW)

SOW: link

SOW Signoffs: (delete those not needed)

Waiver

Pull Request Details

jjscheel commented 1 year ago

This work is not yet staffed.

jjscheel commented 1 year ago

@mustafa7755, @Muhammad-Saadi-Abbasi, it sounds like you guys will be working on this. I've assigned it to both of you not knowing if you're sharing or working on separate pieces. Feel free to unassign yourselves as-appropriate based on assignments.

jjscheel commented 1 year ago

If possible, I'd like an update in the April 25th meeting on when you think you'll have the following dates:

Comments in the issue with these dates would be great.

jjscheel commented 1 year ago

BTW, I should note for this issue that it's marked "At Risk" due to the fact that we had no one assigned.

Given that we have assignees, I'd like their comfort with the SOW and have a basic plan before we move back to "As Planned" status. My hope is that we'll be able to do this in the April 25th meeting at the latest.

jjscheel commented 1 year ago

@Muhammad-Saadi-Abbasi, @mustafa7755, please review the SOW and note that there have been updates to the content based on the feedback from Architecture Review.

This is a good reminder that the contents of the specification may be in flux until we get final AR approval. So, please be advised.

UmerShahidengr commented 1 year ago

Update: Apr 25th, 2023 => The planning phase of this project has been completed, this is the test plan for the viewers to review: Test plan Pointer Masking Ext Goal for next week: Develop the skeleton code (Basic R/W access to the Pointer masking CSR regs) according to the ACT template, and run it on Spike via riscof.

UmerShahidengr commented 1 year ago

@martinmaas, @Adam-pi3 Sir, Please find some time to review the test plan. You are the domain experts, so your comments would be valuable.

martinmaas commented 1 year ago

Apologies for the delayed response (I was on vacation and it took me a while to catch up on everything after coming back). Thank you so much for working on this!

My main feedback is that the latest version of the pointer masking spec has removed instruction pointer masking, which obviates the need for tests related to instructions and to the *ipmen fields.

https://github.com/riscv/riscv-j-extension/blob/master/zjpm-spec.pdf

Some additional feedback:

Please don't hesitate to let @Adam-pi3 and me know if there are any additional questions.

UmerShahidengr commented 1 year ago

Update May 7th, 2023 ⇾ Not much update on this task. Possibly it will get deferred to Q3, 2023 because of upcoming new work (debug native triggers)

jjscheel commented 1 year ago

@martinmaas, thanks for the update. Would you kindly ensure that your additional comments about ACT get into the referenced SOW document (link)?

jjscheel commented 1 year ago

Thanks for the update, @UmerShahidengr. I recognize we're in a holding pattern here.

I'm going to leave on the Agenda for discussion purpsoses at this time.

@martinmaas, @Adam-pi3, you folks should be aware that given the challenges we've had with Code Size Reduction, I've got 1 resource to spend on either Pointer Masking and/or Debug. So, barring some explicit priority guidance, they will be started first-come, first serve. I'll be in touch with what and how we decide.

jjscheel commented 1 year ago

Correction, the challenges with Pointer Masking ACT have been in Zfinx, Zfh, Zdinx, and Zhinx.

jjscheel commented 1 year ago

The discussion this week in the Pointer Masking TG was that @martinmaas would request the Architecture Review Committee to prioritize closure of the items preventing SAIL and ACT work in hopes of keeping this work moving forward.

@martinmaas, please provide an update when available.

UmerShahidengr commented 1 year ago

Update May 23rd, 2023 => Not much update on this task yet.

jjscheel commented 1 year ago

@martinmaas, any update from AR?

Marking as Blocked until we get AR resolution of issues.

Muhammad-Saadi-Abbasi commented 1 year ago

@jjscheel, the tool-chain doesn't has support for Zjpm extension.

jjscheel commented 1 year ago

@martinmaas, @Adam-pi3, what is the status of the toolchain work per @Muhammad-Saadi-Abbasi's question?

martinmaas commented 1 year ago

Pointer masking does not add any new instructions and can thus be used without toolchain support. Once the spec has passed architecture review, the toolchain will need to add some constants, but those shouldn't block ACT or Sail.

An (out of date) example can be found here: https://github.com/martinmaas/riscv-arch-test/commit/f3ba7f8c65496f46a11409b938888a6cb5cb1a56

Please also note that the latest changes requested by the architecture review committee will remove the new CSRs that pointer masking is adding and use the existing *envcfg CSRs.

jjscheel commented 1 year ago

Thanks, @martinmaas! Please keep us posted on the the ARC changes.

UmerShahidengr commented 1 year ago

Update ⇾ June 12th, 2023: Still blocked. No update

jjscheel commented 1 year ago

Agreed. Removing from Agenda. Re-visit next meeting.

jjscheel commented 1 year ago

Moving Projected completion out 6 months based on where we are to 12/30.

UmerShahidengr commented 1 year ago

Update ⇾ July 11th, 2023 Blocked

jjscheel commented 1 year ago

Comment from most recent ARC minutes (July 10) - link

Zjpm (Pointer Masking): Recent feedback from AR was incorporated into an updated spec. Review of this has started, with initial discussion about whether the presence of pointer masking affects the required minimum implemented width of CSRs that hold addresses. The following conclusions were reached:

  • Hardware writes of addresses capture a transformed address in the CSR.
  • Software writes capture the write data value in the CSR unmodified.
  • The implemented WARL width of the register (i.e. how many lsb CSR bits are physically implemented with storage) remains unchanged from the current architecture's WARL specs for each such CSR. For example, if currently tval CSRs support 52 bits valid addresses and pointer masking is implemented and enabled with 16 msb's of masking, the necessary minimum implemented width of tval CSRs remains 52 bits irrespective of whether pointer masking is enabled or disabled.
jjscheel commented 11 months ago

Per ARC minutes from 8/23/2023: https://lists.riscv.org/g/tech-chairs/message/1593

The ARC continued discussion of the Pointer Masking spec, with the primary issue being the extension and enable bit names. The previous suggestion that the enable bit names be tied to the extension names was deemed inappropriate upon reflection because Pointer Masking an attribute of the ABI for given mode of operation, and the extension names are for the bits at higher modes of operation that define the enable bits. It was also suggested that the number of address bits be included in the name (not the number of ignored bits to make it independent of RV64 vs. RV128). As a result, our recommendation is now that the Pointer Masking enable bits be named PM48E in their respective CSRs. This enables would be read-only 0 in RV32 modes of operation.

UmerShahidengr commented 11 months ago

Update ⇾ September 26th, 2023 No update on this.

UmerShahidengr commented 10 months ago

Update ⇾ October 24th, 2023 No update on this.

jjscheel commented 9 months ago

From ARC Minutes for 11/14/2023: https://lists.riscv.org/g/tech-unprivileged/message/585

An updated pointer-masking spec was received, and ARC expects to complete final review and approve next week.

Unblocking. @UmerShahidengr, as they say in racing, "Start your engines!"

UmerShahidengr commented 9 months ago

Update ⇾ November 28th, 2023 Great to hear that. Thanks for the update @jjscheel

UmerShahidengr commented 8 months ago

Update ⇾ December 12th, 2023 @HAMZA-AFZAL404 will work on this in parallel to the Sail implementation

jjscheel commented 8 months ago

Thanks, @UmerShahidengr! Please ensure that Hamza gets a RISC-V Portal id, joins the devpartners community, and places their GH id in their profile. Questions can come directly to me.

UmerShahidengr commented 5 months ago

Update ⇾ March 5th, 2024 Stalled as there is no compiler support for Pointer Masking, so we cant write any assembly tests to verify it.

jjscheel commented 5 months ago

According to the Pointer Masking ISA Status Checklist, "Freeze" tab only CSR access is needed for Pointer Masking support.

@martinmaas, @Adam-pi3, can you confirm that his is the case and assist with an explanation of how test should be written?

martinmaas commented 5 months ago

That's correct – pointer masking doesn't add any additional CSRs or instructions (it only defines new bits in existing CSRs). No compiler support is needed.

UmerShahidengr commented 5 months ago

Pointer Masking defines new bits in existing CSRs, but those bits were reserved earlier. Accessing those reserved bits are giving compile time errors. @HAMZA-AFZAL404 , @muhammad-maarij-zeeshan can you share your insights here.

martinmaas commented 5 months ago

Which compiler are you using, and what is the error message you are seeing? I had written some simple one-off tests (using gcc) and they compiled without problems, but it could be different for LLVM or other versions of GCC. If this does require changes to the compiler, it is probably a very simple patch.

jjscheel commented 5 months ago

Thanks, @martinmaas. @UmerShahidengr, @HAMZA-AFZAL404 , or @muhammad-maarij-zeeshan can you provide some details, please?

HAMZA-AFZAL404 commented 5 months ago

Pointer Masking ACT,s - Test Plan

Hello everyone,

I'm currently working on a test plan for verifying pointer masking in Sail. I've written some test cases, but there are a few that I'm not entirely sure about and would appreciate your guidance on.

Specifically, I'm interested in understanding what will happen when we mask 16 bits of the physical address.

I've outlined my current understanding and approach in the test plan. You can access it here.

If there's is any mistake in this plan. You can edit it and State a reason in the Comment Column.Thank you for your time and assistance.

jjscheel commented 5 months ago

@martinmaas, @Adam-pi3, your guidance on @HAMZA-AFZAL404 's post would be appreciated. Thanks!

martinmaas commented 5 months ago

For physical addresses, pointer masking with 16 bits means that the effective address is the same as if the top 16 bits of the address are set to 0.

Looking at the remaining part of the spreadsheet: Sv48 doesn't necessarily have to result in a page fault – in that case, the effective address is the same as if the top 16 bits are the sign extension of bit 47.

HAMZA-AFZAL404 commented 5 months ago

Thank you, Martin, for your insights. For more clarification i want to discuss a specific scenario related to pointer masking on physical addresses.Correct me if i am wrong please

Let’s consider an example where the original address is 0x0080000000000688. If we apply pointer masking with PMLEN = 16, the resulting address becomes 0x0000000000000688.

So Far as i understand address probably gona be invalid. So it will lead to an access fault.

martinmaas commented 5 months ago

For a physical address, the resulting address with PMLEN=16 becomes 0x0080000000000688. For a virtual address, it becomes 0xFF80000000000688. Whether or not it becomes an access fault depends on whether this part of the address space is valid/mapped.

UmerShahidengr commented 4 months ago

Update ⇾ April 2nd, 2024 @HAMZA-AFZAL404 has been working on ACTs. The work is in development phase

HAMZA-AFZAL404 commented 4 months ago

For a physical address, the resulting address with PMLEN=16 becomes 0x0080000000000688. For a virtual address, it becomes 0xFF80000000000688. Whether or not it becomes an access fault depends on whether this part of the address space is valid/mapped.

Lets say any kind of fault happens on accessing this address what should be wrriten in the tval .The "masked address" or the "unmasked address".

martinmaas commented 4 months ago

Apologies for the delayed response. Section 2.6 describes the details of when the masked or unmasked address should be used. For hardware writes to registers such as tval, pointer masking is applied (i.e., the tag is removed).

UmerShahidengr commented 4 months ago

Update ⇾ April 18th, 2024 ACTs are under development. Almost all tests are ready except pointer masking with sv57 and pointer masking with vector operations. For the time being, we are ignoring ACTs related to pointer masking with vector operations, rest of the tests will be delivered before our next meeting. CC: @HAMZA-AFZAL404

UmerShahidengr commented 4 months ago

Update April 30th, 2024: ACTs are ready but the coverpoint definitions are yet to be added,

jjscheel commented 3 months ago

@UmerShahidengr, what is the status of the coverpoints definitions? Any progress?

martinmaas commented 3 months ago

Thanks @UmerShahidengr for the work on this! Is there a PR for the ACTs, even if the coverpoint definitions are missing?

martinmaas commented 3 months ago

(My reason for asking is that we need to validate the Spike port, and even incomplete ACTs would be very helpful.)

CC: @HAMZA-AFZAL404 @UmerShahidengr