Clarify interaction of CSR width modulation and Hypervisor extension

[JamesKenneyImperas]

Please can you clarify the interaction of CSR width modulation with the Hypervisor extension?

When the Hypervisor extension is implemented, some CSRs are shared by virtual and non-virtual modes. Specifically:

1. All U-mode CSRs are shared by HU-mode and VU-mode;
2. Some S-mode CSRs (e.g. senvcfg, scounteren, and scontext) are shared by HS-mode and VS-mode.

In a system where width modulation is supported, the following could be active at the point when context is switched from non-virtual to virtual mode, or vice-versa:

1. HSXLEN=64 and VSXLEN=32;
2. HUXLEN=64 and VUXLEN=32;
3. HUXLEN=32 and VUXLEN=64.

I believe this means that a change of virtualization state therefore requires implicit CSR width modulation for shared CSRs. Can you please confirm that this is the case?

The ratified CSR width modulation algorithm does not preserve system state when modulation occurs: when transitioning from long to short XLEN, the high part of any non-paired CSR is lost, and information can be lost in either direction if a writable bit in the source view maps to a read-only bit in the target view, or invalidates a WARL restriction in the target view. The case of HUXLEN=32 and VUXLEN=64 looks most problematic, as it seems to obstruct any future extension that adds a CSR such as a pointer register or XLEN-width scratch register to U-mode in a system that implements the Hypervisor extension and width modulation: any trap out of VU-mode with VUXLEN=64 to HS-mode with HSXLEN=64 and HUXLEN=32 will erase the top part of such a CSR, corrupting VU-mode state. A similar problem could occur with HUXLEN=64 and VUXLEN=32 if a shared CSR like the ucause CSR in the old N extension was added, where bit 31 in the 32-bit representation is read-only-zero in the 64-bit version.

In issue #588, I suggested an alternative CSR modulation model that preserves CSR state on XLEN switch (which would eliminate this problem) but that was very unpopular for several reasons, so I've closed that issue. Given that we have to retain the ratified CSR modulation algorithm, it would be very helpful to have the behavior when the Hypervisor extension is also implemented to be explicitly documented.

Thanks.

[gfavor]

The ARC discussed this today and agreed on the following:

The answer to the question as it applies to the current RISC-V architecture, is Yes (i.e. your understanding of the CSR width modulation in your example is correct).

This is not an issue for Unpriv CSRs since they have a defined width of XLEN. And currently there are no U-mode CSRs - for which this issue would arise if they were defined to have UXLEN width. But the POR for U-mode CSRs, whenever such come to exist in the architecture, is that they will also be defined to have XLEN width.

[JamesKenneyImperas]

Hi Greg,

I'm not really understanding the distinction you're making between XLEN and UXLEN in this context. It seems to me that unless U-mode CSRs are implicitly always UXLEN (or VUXLEN/HUXLEN) then inconsistencies will arise elsewhere.

Consider a system with variable UXL and the Vector extension. That extension has the vtype U-mode CSR, and, when the type is illegal, that specification says that the vill bit, at position XLEN-1, gets set to 1. What does this mean if an attempt is made to set an illegal vtype when executing with UXL specifying XLEN=32 in a system for which implemented XLEN=64? I would expect bit 31 to be set, not bit 63, since the result must obviously be visible to U-mode. The vector specification doesn't say that, however: throughout, it's talking only about XLEN, and it's assuming that means UXLEN (I think!). [As an aside, I'd also expect the vill bit to appear to commute up and down the vtype CSR when effective UXLEN changes, but that behavior is one of the possible outcomes with the ratified modulation algorithm, so I'm not concerned about that.]

Are you saying that the vector specification (and any other specification that adds shared U-mode and S-mode HS/VS CSRs) needs to take into account the possibility that the extension is used in an implementation with the Hypervisor and variable XLEN and document that?

If the ARC can take the action to ensure appropriate clarification is added to the Privileged Specification then that would be great.

Thanks!

[JamesKenneyImperas]

A further point to consider with the Vector extension: Suppose that SXL implies XLEN=64, UXL implies XLEN=32 and an illegal vsetvli instruction is executed in S-mode. Does the vill bit get set at position 63 or 31? I would expect it to be set in position 31, but after reading your response above, I'm not sure.

Thanks.

[allenjbaum]

I'm going to jump right in here in order to make a fool of myself. I think of XLEN ia UXLEN when the hart is in Umode, SXLEN when it is in Smode, and MXLEN when it is in Mmode. (also, I'm not sure"implies" is the correct word there - it sets the XLEN for a mode). So in your example above, if that bit is defined to be at position XLEN-1, then it will be in bit 63 for Smode, and bit 31 for Umode, which is (from a SW point of view) exactly what you want to allow SW to test it as the sign bit.

(oh, and I' like to amend the priv spec in a non-backwards compatible way to make MXL readonly, and I expect there will be no implementations that do otherwise, so no harm, no fowl, ugly corner cases go away....)

On Wed, Dec 13, 2023 at 2:51 AM JamesKenneyImperas @.***> wrote:

A further point to consider with the Vector extension: Suppose that SXL implies XLEN=64, UXL implies XLEN=32 and an illegal vsetvli instruction is executed in S-mode. Does the vill bit get set at position 63 or 31? I would expect it to be set in position 31, but after reading your response above, I'm not sure.

Thanks.

— Reply to this email directly, view it on GitHub https://github.com/riscv/riscv-isa-manual/issues/1173#issuecomment-1853685566, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHPXVJWNLIFXKFI7WE722GDYJGCCFAVCNFSM6AAAAABAKYSMXKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNJTGY4DKNJWGY . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[JamesKenneyImperas]

Thanks Allen, that sounds right. So there are possible implicit width modulation events on any transition between privilege levels. I need to have a think about the implications of that, but in any case it would be really helpful to add some explicit text to the specification that makes this clear.

[gfavor]

There is such (that talks about XLEN versus the *XLEN's) - see Priv section 3.1.6.2.

[JamesKenneyImperas]

Hi Greg,

Yes, I think that's the right section to describe this, but it would be very helpful to make it explicit. Perhaps something like:

Some CSRs have their width defined by a specific privilege level: for example, a CSR described as SXLEN in this manual has a width defined by the current SXL setting and will undergo a width modulation event when SXL changes. Other CSRs have their width defined by the current privilege level, and are described as of width XLEN in this manual. Such CSRs will undergo a width modulation event on a transition between privilege levels with differing XLEN.

I'm sure there's a better way to say it, but is that what is intended?

There's also this note in the version of the specification I'm looking at:

To reduce hardware complexity, the architecture imposes no checks that lower-privilege modes have XLEN settings less than or equal to the next-higher privilege mode. In practice, such settings would almost always be a software bug, but machine operation is well-defined even in this case.

I don't think that's true any more is it? I need to check to see if that's still in the raw source on GitHub.

[gfavor]

That section already describes the difference between XLEN and *XLEN's (and how they each interact with CSR width modulation). But your suggested text may be a useful clarification. Although probably this clarification would best belong in section 2.6 - as the first paragraph (which then sets some addiitonal context for the rest of the section).

I suggest you go ahead and create a PR that adds your suggested text at the beginning of section 2.6, and then let's see what Andrew thinks.

[JamesKenneyImperas]

Hi Greg - I'll do that. I'm a bit busy with some other things at the moment, but I'll try to get to it soon.