Skip to content

Updating Ssnpm_H testplan - #3047

Open
Ammarahwakeel wants to merge 1 commit into
riscv:act4from
Ammarahwakeel:ssnpm-H
Open

Ammarahwakeel wants to merge 1 commit into
riscv:act4from
Ammarahwakeel:ssnpm-H

Conversation

@Ammarahwakeel

@Ammarahwakeel Ammarahwakeel commented Oct 29, 2026 •

Copy link
Copy Markdown
Contributor

Test plan updates for #3011. I rewrote Ssnpm_H.yaml to follow the same pattern as Ssnpm.yaml. The coverpoints and tests will be added to this PR once the plan is final.

  • VS and VU masking: cp_vs_pmm and cp_vu_pmm sweep henvcfg.PMM/senvcfg.PMM over seven (vsatp, hgatp) pairs: (Bare, Bare/Sv39x4/Sv48x4/Sv57x4) and the matching paged pairs. The other coverpoints use one Bare pair and one paged pair, each the widest the DUT supports.
  • HLV/HSV, HLVX, MXR: HLV.D/HSV.D from HS- and U-mode with SPVP 0 and 1 check the PMM source (henvcfg, senvcfg or HUPMM); HLVX and MXR are never masked.
  • HFENCE.GVMA: cp_henvcfg_pmm_change_hfence and cp_hupmm_change_hfence cover the three cases in the spec, with a no-fence twin.
  • Also: the instruction list, Zicfiss, misaligned accesses, stval/htval on faults, jalr (fetches not masked), the G stage not masked, and PMM clearing on VSXL/vsstatus.UXL changes.

The notes give the expected traps. Projected size on a hart with PMLEN 7 and 16, Sv57 and Sv57x4: about 2,200 bins, 940 traps and 500k instructions, in four chunks:

Chunk Coverpoints Bins Traps Instructions
VS-mode cp_vs_*, cp_henvcfg_pmm_change_*, cp_pmm_vsxl_clear ~930 ~380 ~210k
VU-mode cp_vu_*, cp_pmm_vsuxl_clear ~900 ~360 ~180k
HLV/HSV/HLVX from HS-mode cp_hlv_hs_*, cp_hlvx_hs_pmm ~210 ~110 ~60k
HLV/HSV/HLVX from U-mode cp_hlv_u_*, cp_hlvx_u_pmm, cp_hupmm_change_hfence ~180 ~90 ~60k

@github-actions github-actions Bot added status: needs-review PR is ready for a review Tests Issues or pull requests related to the test generator or handwritten tests labels Oct 29, 2026
@Ammarahwakeel

Copy link
Copy Markdown
Contributor Author

Do we want to include the cp_pmm_jalr, cp_pmlen_misaligned_word, cp_hardware_csr_writes_fault coverpoints here too? so that after configuring in HS mode the corresponding test cases run in vs/vu mode ?
Or are these considered repititive here ?

@jordancarlin

Copy link
Copy Markdown
Collaborator

Do we want to include the cp_pmm_jalr, cp_pmlen_misaligned_word, cp_hardware_csr_writes_fault coverpoints here too? so that after configuring in HS mode the corresponding test cases run in vs/vu mode ? Or are these considered repititive here ?

I think we probably should. We should test all of the standard pointer masking coverpoints in VS and VU mode.

@Ammarahwakeel

Ammarahwakeel commented Oct 29, 2026 •

Copy link
Copy Markdown
Contributor Author

1- Fo simplicity, deciding to drop hgatp crosses with vsatp, since masking only depends on vsatp.
2- The PMM fields that do not apply to a case are enabled when
the one that applies is 00, and 00 otherwise; The PMM bits should be zeroed out , outside the loop

@davidharrishmc

David Harris (davidharrishmc) commented Oct 29, 2026 •

Copy link
Copy Markdown
Collaborator

Pointer masking is not supposed to apply to G-stage translation. Add one test case where the answer would be wrong if it was applied, so we confirm it not being applied.

@davidharrishmc

Copy link
Copy Markdown
Collaborator

When testing a particular PMM, set the other ones to something different.

@davidharrishmc

Copy link
Copy Markdown
Collaborator

Notes: "the PMM fields that do not apply to a case are enabled when
the one that applies is 00, and 00 otherwise" Make sure pmm values are in the outer loop so not many T-SBI calls are made to set them up.

Comment thread testplans/priv/Ssnpm_H.yaml Resolved
Comment thread testplans/priv/Ssnpm_H.yaml Resolved
Comment thread testplans/priv/Ssnpm_H.yaml Resolved
Comment thread testplans/priv/Ssnpm_H.yaml Resolved
Comment thread testplans/priv/Ssnpm_H.yaml Resolved
Comment thread testplans/priv/Ssnpm_H.yaml Resolved
Comment thread testplans/priv/Ssnpm_H.yaml Resolved
Comment thread testplans/priv/Ssnpm_H.yaml Resolved
@davidharrishmc

Copy link
Copy Markdown
Collaborator

Check number of traps occurring, so runtime is not excessive.

@Ammarahwakeel

Ammarahwakeel commented Oct 31, 2026 •

Copy link
Copy Markdown
Contributor Author

1- Added all standard pointer masking coverpoints to run in vs and vu mode
2- Simplified the crosses with vsatp = Bare, hgatp is swept over Bare/Sv39x4/Sv48x4/Sv57x4. With vsatp paged, hgatp is the matching width only, since the spec says the GPA-width issue doesn't apply when vsatp != Bare. That is 7 combinations instead of 16.
3- when one PMM field is under test the others are set to a different value (11 when it is 00, 00 when it is 10/11),in the outer loop.

Questions:

Should we separate out the tests and hence the testplans for VS and VU modes, because in this case the test will be much lengthy.
For both VS and VU mode, we are enabling masking from HS mode. I could not find much clear answer from spec, but I am supposing we can enable VU masking from VS mode too?

@davidharrishmc

Copy link
Copy Markdown
Collaborator

AI review. Please apply your judgement about whether these comments are right.

Thanks, this is a big step forward. The field isolation (other PMM fields set to a different value, PMM in the outer loop), the paged-vsatp sweep with matching hgatp widths, the vsstatus.MXR × sstatus.MXR cross, HLV/HSV under MXR, the G-stage-not-masked case and the VS/VU versions of the standard coverpoints all look right. The bin count is also down from about 43k to about 10k.

Answers to your questions:

  • Should VS and VU get separate tests and testplans because the test will be long? Keep them in one suite and one testplan. In the generator, put VS and VU in separate chunks (files) so they run in parallel; item 5 below gives a layout. The size changes below make each chunk short.
  • Can VU masking be enabled from VS-mode too? Yes. senvcfg isn't virtualized: VS-mode reads and writes the real senvcfg, so setting senvcfg.PMM from VS is how a real guest kernel enables masking for its user mode. With Ssstateen, this needs hstateen0.SENVCFG = 1. henvcfg.PMM can only be written from HS. It's worth covering, see item 9.
  • Should jalr, misaligned and hardware CSR writes run in VS/VU too? Yes, as Jordan said, and the plan now has them. Item 10 keeps the misaligned ones deterministic.
  • Can hgatp stop being crossed with vsatp, since masking depends only on vsatp? Using only the matching hgatp width when vsatp is paged works. With vsatp = Bare, hgatp still decides what an unmasked tag does, so keep a few hgatp modes there, including Sv39x4 (item 6).

At about 10k bins the plan would still generate roughly 2M dynamic instructions and close to 6k traps, about 20 files at our 100k-per-file guideline. These changes should bring it to about 2k bins and under 500k instructions, in chunks of 50–70k:

Size

  1. cp_vs_pmlen_masking / cp_vu_pmlen_masking: cross the instruction list with one Bare and one paged (vsatp, hgatp) pair only, and tags {0x0000, 0x0400, 0xFFFF}. cp_vs_pmm / cp_vu_pmm already sweep every mode pair with ld/sd.
  2. The six MXR coverpoints: use only the largest supported PMM, tags {0x0000, 0xFFFF}, and one Bare plus one paged pair. Keep the HS-mode HLV MXR pair (SPVP = 0/1) and drop the U-mode copies, which exercise the same MXR rule.
  3. The HLV, HLVX and jalr coverpoints: one Bare and one paged pair. HLVX: hlvx.wu only.
  4. Add a line to the notes giving the expected trap count per chunk.
  5. Chunk the generator by VS, VU, HLV from HS-mode and HLV from U-mode, each under 100k instructions.

Coverage

  1. Add (vsatp, hgatp) = (Bare, Sv39x4) to the swept pairs. On a hart with only Sv39x4, it is the only case where a guest physical address goes through G-stage translation. Also update the PR description, which still lists Sv39x4 for every coverpoint.
  2. Add a no-fence twin of cp_henvcfg_pmm_change_hfence for PMM changes the spec doesn't list (Sv39x4 with any PMLEN, Sv48x4 with PMLEN 7, paged vsatp). These must take effect without an HFENCE. Also add the 10 ↔ 11 direction on Sv57x4, which the HFENCE rule covers.
  3. Add VS/VU versions of cp_pmlen_zicfiss_amo / cp_pmlen_zicfiss_ssp (gated on Zicfiss), and a cp_pmm_uxl_clear equivalent for hstatus.VSXL / vsstatus.UXL = 32 where those fields are writable.
  4. In cp_vu_pmm, add a bin where VS-mode writes senvcfg.PMM.

Determinism

  1. Misaligned coverpoints: use only the enabled PMM with fully masked tags (0x0400 for PMM 10, 0xFFFF for PMM 11), as base Ssnpm does. Misaligned vs. page/access-fault priority is implementation-defined, so a faulting misaligned access has no single expected trap on harts without misaligned support.
  2. hgatp = Bare: state that the tagged addresses lie outside the PA width or in a PMA hole, so an unmasked access can't alias DRAM.
  3. The partially masked Sv57 note: say the masked upper-half addresses are left unmapped, so the fault is guaranteed rather than "may reach another mapped page".
  4. prefetch.w: it's a hint, so don't gate it on Zicbop or try to observe a cache effect. Keep it as an ungated, coverage-only bin.

Small fixes

  1. Gate the menvcfg.PMM / mseccfg.PMM "other field" settings on Smnpm / Smmpm. Say "11 (10 if PMLEN 16 is unsupported)".
  2. cp_*_hardware_csr_writes_fault: medeleg must also delegate page faults and guest-page faults to HS, not just access faults.
  3. MXR coverpoints: the loop text lists MXR first but calls PMM outermost. Pick one.
  4. Typos: title "VU-mode )" and "Tag patterns(A_upper_bits)".

Once the plan is settled, please add the covergroup and generator updates to this PR, so the plan, coverpoints and tests merge together.

@Ammarahwakeel

Copy link
Copy Markdown
Contributor Author

Addressed almost all points of the AI review, except following changes :

  • when we say that we want to reduce vsatp * hgatp to one paged and one bare cross, i initially added like { (sv57, sv57x4), (bare, bare/sv57x4)}, but if a DUT does not implement that specific paged MODE, the coverpoints will not get hit, So I made the pairs a fallback chain that always runs exactly once:
    PAGED_PAIR is the first supported of (Sv57, Sv57x4), (Sv48, Sv48x4), (Sv39, Sv39x4).
    BARE_PAIR is the first supported of (Bare, Sv57x4), (Bare, Sv48x4), (Bare, Sv39x4), (Bare, Bare).
    The support guards are exclusive, so a narrower pair adds no bin when a wider one is supported.

  • For the cp_pmm_uxl_clear coverpoint, the spec lines says

Setting UXL/SXL/MXL to 1 will clear the corresponding pointer masking configuration bits.

Like the spec doesn't name VSXL or vsstatus.UXL, but they are the VS-mode counterparts of SXL and UXL, so I added them,

@Ammarahwakeel

Copy link
Copy Markdown
Contributor Author

Also for the coverpoints and tests, would it be more easier to review them in separate PR, instead of adding them here?

@jordancarlin

Copy link
Copy Markdown
Collaborator

Also for the coverpoints and tests, would it be more easier to review them in separate PR, instead of adding them here?

Seems fine to add them here. Then we can review the whole thing at the same time since the testplan, coverpoints, and tests are all related.

@davidharrishmc

Copy link
Copy Markdown
Collaborator

AI review:

Thanks, this addresses most of the last round: the misaligned cps are deterministic, the no-fence twin and the 10 <-> 11 case are in, prefetch.w is ungated, Zicfiss and the XL-clear cps are added, and the menvcfg/mseccfg settings are gated. The BARE_PAIR/PAGED_PAIR fallback is a good way to handle unsupported modes. Agreed with Jordan on adding the coverpoints and tests here.

Remaining items:

  1. cp_*_hardware_csr_writes_fault: on a guest-page fault htval is either zero or GPA >> 2, and on other traps it is zero. With PMM = 10, tags 0x0002, 0xFF00 and 0xFFFF leave unmasked bits, so the faulting address is invalid, and stval for an invalid address can legally be a different invalid address. Use only 0x0000 and fully masked tags (0x0400 for PMM 10; 0x0400 and 0xFFFF for PMM 11), and drop "stval holds the untransformed address" from the HLVX expectation or limit it to valid addresses.
  2. MXR coverpoints and the VS-writer bins of cp_vu_pmm: with PMM = 10, tag 0xFFFF sign-extends to itself, so these bins give the same result whether MXR (or the VS write) took effect or not. Use 0x0400, which both PMLENs mask, or pick the tag per PMM as the misaligned coverpoints do.
  3. Add (Bare, Sv39x4) to the pairs of cp_vs_pmm and cp_vu_pmm and to the notes. The misaligned and stval coverpoints can use BARE_PAIR/PAGED_PAIR instead of six pairs.
  4. With 1 and 3, the plan comes to about 2,200 bins, 930 traps and 500k instructions. Please add the chunk layout (VS, VU, HLV from HS, HLV from U) and the expected trap count per chunk to the notes.
  5. When Ssstateen is implemented, VS-mode can write senvcfg only with hstateen0.ENVCFG = 1.
  6. cp_*_pmlen_zicfiss_ssp: the pushes leave value_new at A', so each sspopchk against value_old raises a software-check exception. Reseed value_old before the pops (base Ssnpm has the same problem).
  7. The partially masked Sv57 note still says the access "may reach another mapped page"; say those addresses are left unmapped, or mapped to the alias page.
  8. hgatp = Bare: tag 0x0002 (bit 49) and the unmasked part of 0xFFFF are inside a 56-bit physical address. Use them there only when the physical address width is at most 49 bits, or drop them for (Bare, Bare).

Smaller: list cp_henvcfg_pmm_change_no_hfence in the trap notes; restore the HLV/HSV, HLVX and MXR sentence in the description; the misaligned expectation can name the address-misaligned trap; use the Smnpm/Smmpm PMLEN support for menvcfg/mseccfg; make the alias pages non-executable for the jalr coverpoints; cbo.zero/cbo.clean also need menvcfg.CBZE/CBCFE; the PR description still describes the old sweeps.

@davidharrishmc

Copy link
Copy Markdown
Collaborator

Sounds good adding vsxl to cp_pmm_uxl_clear. Perhaps the name shouldn't be uxl anymore?

Let's get the testplan finalized first and then do coverpoints and tests.

@Ammarahwakeel

Copy link
Copy Markdown
Contributor Author

Let's get the testplan finalized first and then do coverpoints and tests.

Pushed the changes, ready for another review.

@davidharrishmc

David Harris (davidharrishmc) commented Nov 4, 2026 •

Copy link
Copy Markdown
Collaborator

I pushed f6c808c and 03eca26 with the last small fixes to the plan:

  • Rules: cp_vs_pmm and cp_vu_pmm now list pmlen_mode_depend.
  • (Bare, Bare) note: now says 0x0400 leaves bit 58 and 0xFF00 with PMLEN 7 leaves bit 56, so both can be used with any PA width up to 56.
  • jalr: the alias pages are non-executable in each paged stage, not "both stages"; with (Bare, Bare) the fetch is an access fault anyway.
  • Misaligned: a hart without misaligned support may take an access fault as well as an address-misaligned trap.

I also updated the PR description, which still described the old sweeps, and added the projected size per chunk there (about 2,200 bins, 940 traps and 500k instructions on a hart with PMLEN 7 and 16, Sv57 and Sv57x4). With this the plan looks ready to me, so please go ahead with the coverpoints and tests on this PR.

@davidharrishmc

Copy link
Copy Markdown
Collaborator

Merging this part. Let's put tests and coverpoints in the next PR, along with any changes that might come up to the testplan.

@Ammarahwakeel

Copy link
Copy Markdown
Contributor Author

Merging this part. Let's put tests and coverpoints in the next PR, along with any changes that might come up to the testplan.

Okay, noted.

@github-actions github-actions Bot added status: approved PR has been approved and is waiting for checks or merge. and removed status: needs-review PR is ready for a review labels Nov 4, 2026
auto-merge was automatically disabled November 5, 2026 04:17

Head branch was pushed to by a user without write access

Co-authored-by: David Harris <74973295+davidharrishmc@users.noreply.github.com>
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Signed-off-by: Ammarahwakeel <ammarahwakeel9@gmail.com>
@Ammarahwakeel

Copy link
Copy Markdown
Contributor Author

I am sorry prof. , I did not see that two of my commits were not verified, just fixed that. Now it can be merged

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

status: approved PR has been approved and is waiting for checks or merge. Tests Issues or pull requests related to the test generator or handwritten tests

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants