1. Tech-Privileged
  2. Topics

Why must misa.H be writable (RVA22)?

Jonathan Behrens <behrensj@...>
 

I think the fact that the current platform spec draft lacks any way for S-mode to toggle misa.H, for S-mode to request a specific value, or even a way for configuring M-mode to set/unset misa.H at boot, is a strong indication that this isn't a broadly demanded feature. It seems reasonable to allow misa.H to be writable for the subset of cases that require it, but I see no reason to require it as part of the profile.

Jonathan


On Wed, Sep 8, 2021 at 10:54 PM Andrew Waterman via lists.riscv.org <andrew=sifive.com@...> wrote:


On Wed, Sep 8, 2021 at 12:57 PM Greg Favor <gfavor@...> wrote:
On Wed, Sep 8, 2021 at 12:45 PM Andrew Waterman <andrew@...> wrote:
My own (possibly unpopular) take is that implementing writable misa.H is a mess, and the benefits don’t come close to justifying the effort.

I don't disagree.  Which begs the question of whether there should be any encouragement or expectation that any implementations (barring inevitable exception cases) of misa should have writable bits.  Having all bits hardwired to 0 or 1 saves a bunch of design and DV work.  The obvious next example to question is whether the V bit should be writable or not.

I'm not arguing for disallowing having writable bits.  But as a form of architectural guidance, when might it be considered justifiable to have writable H and/or V bits (or other misa bits)?  Is it just the rare implementation exception cases?

Without a doubt, there’s value in building machines that can faithfully emulate less-capable machines. With that in mind, writable misa.H is a well architected feature. Whether it rises to the level of a mandate in this platform is another matter, though.


Greg
andrew@...
 



On Wed, Sep 8, 2021 at 12:57 PM Greg Favor <gfavor@...> wrote:
On Wed, Sep 8, 2021 at 12:45 PM Andrew Waterman <andrew@...> wrote:
My own (possibly unpopular) take is that implementing writable misa.H is a mess, and the benefits don’t come close to justifying the effort.

I don't disagree.  Which begs the question of whether there should be any encouragement or expectation that any implementations (barring inevitable exception cases) of misa should have writable bits.  Having all bits hardwired to 0 or 1 saves a bunch of design and DV work.  The obvious next example to question is whether the V bit should be writable or not.

I'm not arguing for disallowing having writable bits.  But as a form of architectural guidance, when might it be considered justifiable to have writable H and/or V bits (or other misa bits)?  Is it just the rare implementation exception cases?

Without a doubt, there’s value in building machines that can faithfully emulate less-capable machines. With that in mind, writable misa.H is a well architected feature. Whether it rises to the level of a mandate in this platform is another matter, though.


Greg
Phil McCoy
 

Disabling FP and Vector units (or any extension that adds a lot of user-privileged stage) can be useful for lazy context switching, but that should be done via mstatus.FS/XS rather than misa bits.  Anyway, that doesn't seem applicable to the H-extension.

Testing software emulation of the H-extension on a CPU that implements the H-Extension in hardware is one possible use case, but I don't think it is important enough to justify mandating writable misa.H.  The softies can always test their stuff on QEMU :-)  The same argument could also be applied to misa.S, but I'm not aware of any recommendation that misa.S be writable.

-Phil
Greg Favor
 

On Wed, Sep 8, 2021 at 12:45 PM Andrew Waterman <andrew@...> wrote:
My own (possibly unpopular) take is that implementing writable misa.H is a mess, and the benefits don’t come close to justifying the effort.

I don't disagree.  Which begs the question of whether there should be any encouragement or expectation that any implementations (barring inevitable exception cases) of misa should have writable bits.  Having all bits hardwired to 0 or 1 saves a bunch of design and DV work.  The obvious next example to question is whether the V bit should be writable or not.

I'm not arguing for disallowing having writable bits.  But as a form of architectural guidance, when might it be considered justifiable to have writable H and/or V bits (or other misa bits)?  Is it just the rare implementation exception cases?

Greg
Phil McCoy
 

Thanks Andrew and Gregg.  I'll ask the question on unixplatformspec.

Cheers,
Phil
andrew@...
 

My own (possibly unpopular) take is that implementing writable misa.H is a mess, and the benefits don’t come close to justifying the effort.

On Wed, Sep 8, 2021 at 12:32 PM Greg Favor <gfavor@...> wrote:
Phil,

Yes, this would be a good question for the platforms (not profiles) group to discuss .  I'll go ahead and raise it to the group.  The H extension does explicitly "encourage" implementations to not hardwire this misa bit (to '1') "so that the extension may be disabled", but obviously that is not a requirement.  So the question is whether the Base OS-A platform spec should allow implementations to ignore that "encouragement" by the H extension spec, or not.  The answer may very well be "yes, that should be allowed".  But this is worth a discussion.

I'm also cc'ing John (the H extension lead architect) to get his thoughts behind why the arch spec contains that "encouragement".

Greg

On Wed, Sep 8, 2021 at 11:45 AM Andrew Waterman <andrew@...> wrote:
I recommend visiting the tech-unixplatformspec mailing list.  The profile and platform specs are far from being frozen, and so your input may well be impactful.

On Wed, Sep 8, 2021 at 11:38 AM Phil McCoy <pnm@...> wrote:
Hi,


 


Does anyone know why the RV22A profile draft (https://github.com/riscv/riscv-platform-specs/blob/main/riscv-platform-spec.adoc) mandates the following:


 




  • misa



    •  If the H extension is supported then the H bit must be writable.








 


A RISC-V CPU with H hard-wired to 1 can still run any "correct" non-hypervisor software (e.g. a normal OS).  Is there some compelling use case where non-hypervisor software wants to count on having the hypervisor extension disabled in hardware?


 


On the other hand, this requirement creates a substantial additional burden on the CPU design and verification.  The CPU logic must include both "enabled" and "disabled" variants of every detail in the H extension, all of which have to be verified.


 


If this is not the right forum to discuss this topic, please feel free to point me in the right direction.


 


Regards,


Phil McCoy


 
Greg Favor
 

Phil,

Yes, this would be a good question for the platforms (not profiles) group to discuss .  I'll go ahead and raise it to the group.  The H extension does explicitly "encourage" implementations to not hardwire this misa bit (to '1') "so that the extension may be disabled", but obviously that is not a requirement.  So the question is whether the Base OS-A platform spec should allow implementations to ignore that "encouragement" by the H extension spec, or not.  The answer may very well be "yes, that should be allowed".  But this is worth a discussion.

I'm also cc'ing John (the H extension lead architect) to get his thoughts behind why the arch spec contains that "encouragement".

Greg

On Wed, Sep 8, 2021 at 11:45 AM Andrew Waterman <andrew@...> wrote:
I recommend visiting the tech-unixplatformspec mailing list.  The profile and platform specs are far from being frozen, and so your input may well be impactful.

On Wed, Sep 8, 2021 at 11:38 AM Phil McCoy <pnm@...> wrote:
Hi,
 
Does anyone know why the RV22A profile draft (https://github.com/riscv/riscv-platform-specs/blob/main/riscv-platform-spec.adoc) mandates the following:
 
  • misa
    •  If the H extension is supported then the H bit must be writable.
 
A RISC-V CPU with H hard-wired to 1 can still run any "correct" non-hypervisor software (e.g. a normal OS).  Is there some compelling use case where non-hypervisor software wants to count on having the hypervisor extension disabled in hardware?
 
On the other hand, this requirement creates a substantial additional burden on the CPU design and verification.  The CPU logic must include both "enabled" and "disabled" variants of every detail in the H extension, all of which have to be verified.
 
If this is not the right forum to discuss this topic, please feel free to point me in the right direction.
 
Regards,
Phil McCoy
 
andrew@...
 

I recommend visiting the tech-unixplatformspec mailing list.  The profile and platform specs are far from being frozen, and so your input may well be impactful.


On Wed, Sep 8, 2021 at 11:38 AM Phil McCoy <pnm@...> wrote:
Hi,
 
Does anyone know why the RV22A profile draft (https://github.com/riscv/riscv-platform-specs/blob/main/riscv-platform-spec.adoc) mandates the following:
 
  • misa
    •  If the H extension is supported then the H bit must be writable.
 
A RISC-V CPU with H hard-wired to 1 can still run any "correct" non-hypervisor software (e.g. a normal OS).  Is there some compelling use case where non-hypervisor software wants to count on having the hypervisor extension disabled in hardware?
 
On the other hand, this requirement creates a substantial additional burden on the CPU design and verification.  The CPU logic must include both "enabled" and "disabled" variants of every detail in the H extension, all of which have to be verified.
 
If this is not the right forum to discuss this topic, please feel free to point me in the right direction.
 
Regards,
Phil McCoy
 
Phil McCoy
 

Hi,
 
Does anyone know why the RV22A profile draft (https://github.com/riscv/riscv-platform-specs/blob/main/riscv-platform-spec.adoc) mandates the following:
 
  • misa
    •  If the H extension is supported then the H bit must be writable.
 
A RISC-V CPU with H hard-wired to 1 can still run any "correct" non-hypervisor software (e.g. a normal OS).  Is there some compelling use case where non-hypervisor software wants to count on having the hypervisor extension disabled in hardware?
 
On the other hand, this requirement creates a substantial additional burden on the CPU design and verification.  The CPU logic must include both "enabled" and "disabled" variants of every detail in the H extension, all of which have to be verified.
 
If this is not the right forum to discuss this topic, please feel free to point me in the right direction.
 
Regards,
Phil McCoy
 

1 - 9 of 9