Date   

Re: [RISC-V] [tech-tee] The proposal of sPMP

Bill Huffman
 

Perhaps we should rename the sPMP to something that sounds more like the simplified page table idea. Maybe Memory Protection Unit. The fact that it resembles PMP doesn't have to appear in the name.

Bill

-----Original Message-----
From: tech-privileged@... <tech-privileged@...> On Behalf Of Paolo Bonzini
Sent: Monday, April 19, 2021 5:28 PM
To: tech-privileged@...
Subject: Re: [RISC-V] [tech-privileged] [RISC-V] [tech-tee] The proposal of sPMP

EXTERNAL MAIL


On 19/04/21 22:17, Bill Huffman wrote:
Nick,

For security reasons, PMP exceptions will almost always be handled in
M-mode. sPMP exceptions typically want to be handled in S-mode. I
don't think it ever makes sense to have the two types routed to the
same exception code. So that seems out to me.

I don't think it ever makes sense to handle PMP access faults in
S-mode. It's the wrong privilege level (and S-mode can't write the
PMP either).

If we don't allow sPMP and paging at the same time, then the two can
use the same exception codes. Perhaps the only issue is the name.
The name "page fault" doesn't seem to fit with an sPMP exception. If
that's the issue, then let's see if we can solve that.
It really seems to me that the sPMP is not really a PMP but a simplified page table format (which vaguely reminds me of PowerPC BAT registers)...

Paolo


Re: [RISC-V] [tech-tee] The proposal of sPMP

Paolo Bonzini
 

On 19/04/21 22:17, Bill Huffman wrote:
Nick,
For security reasons, PMP exceptions will almost always be handled in
M-mode. sPMP exceptions typically want to be handled in S-mode. I
don't think it ever makes sense to have the two types routed to the
same exception code. So that seems out to me.
I don't think it ever makes sense to handle PMP access faults in
S-mode. It's the wrong privilege level (and S-mode can't write the
PMP either).
If we don't allow sPMP and paging at the same time, then the two can
use the same exception codes. Perhaps the only issue is the name.
The name "page fault" doesn't seem to fit with an sPMP exception. If
that's the issue, then let's see if we can solve that.
It really seems to me that the sPMP is not really a PMP but a simplified page table format (which vaguely reminds me of PowerPC BAT registers)...

Paolo


Re: [RISC-V] [tech-tee] The proposal of sPMP

Bill Huffman
 

Nick,

For security reasons, PMP exceptions will almost always be handled in M-mode. sPMP exceptions typically want to be handled in S-mode. I don't think it ever makes sense to have the two types routed to the same exception code. So that seems out to me.

I don't think it ever makes sense to handle PMP access faults in S-mode. It's the wrong privilege level (and S-mode can't write the PMP either).

If we don't allow sPMP and paging at the same time, then the two can use the same exception codes. Perhaps the only issue is the name. The name "page fault" doesn't seem to fit with an sPMP exception. If that's the issue, then let's see if we can solve that.

Bill

-----Original Message-----
From: tech-tee@... <tech-tee@...> On Behalf Of Nick Kossifidis
Sent: Monday, April 19, 2021 3:51 PM
To: Andrew Waterman <andrew@...>
Cc: bichengyang@...; tech-privileged@...; tech-tee@...
Subject: Re: [RISC-V] [tech-tee] The proposal of sPMP

EXTERNAL MAIL


Στις 2021-04-19 01:43, Andrew Waterman έγραψε:

I'm going to push back against the proposal to allocate new cause
values for sPMP faults. Allocating new cause values has knock-on
effects and incremental costs throughout the architecture (with
respect to virtualization and delegation, in particular), and so the
bar for adding new ones needs to be set high.

Many of us do not believe that composing sPMP and paging is an
essential use case to support--and, in fact, some of us would prefer
the architectural economy of disallowing their composition. Even if
we do support it, software has sufficient information to distinguish
sPMP faults from page faults. The process is indeed cumbersome, as
y'all have discussed. But it need not be a performance sink--first of
all, because this isn't a common case, and second, because the checks
can be performed almost entirely off the critical path. (The sPMP
checks only need to be performed if the paging subsystem determines
the fault shouldn't have occurred--similar to Linux's existing
handling of spurious page faults due to lazy shootdowns on upgrades.)
Right now a system without MMU or with satp set to bare mode, will raise an access fault regardless of PMP/ePMP being active, and that access fault may be handled by M-mode or delegated to S-mode as-is through medeleg. If sPMP is present the same system will get an access fault if sPMP is disabled and a page fault if sPMP is active, not only this is inconsistent, it also doesn't make sense to return a page fault when paging is disabled or even unavailable. Even if we don't use sPMP together with MMU the proposal of raising page faults on sPMP failures is a bit off. I believe we should either treat sPMP in the same way as PMP/ePMP and trigger access faults since we are dealing with physical memory, or treat access faults from S-mode in the same way regardless of sPMP. If we decide to treat access faults from S-mode as page faults so that we can delegate them all together to S-mode through medeleg, I'd expect to be able to do this regardless of sPMP being active.

Regards,
Nick


Re: [RISC-V] [tech-tee] The proposal of sPMP

Paolo Bonzini
 

On 19/04/21 21:23, Nick Kossifidis wrote:
A scenario we discussed at some point was a trusted hypervisor running on HS mode, with e.g. Linux and a trusted service running on VS mode. The trusted hypervisor is usually very small/simple and may not use paging, so hgatp will be set to bare and it'll fallback to PMP/ePMP as the current hypervisor spec mandates. With sPMP the hypervisor will be able to configure its own regions and also isolate Linux from the trusted service
I don't see much difference between setting up sPMP and a constant page table for the guest. It's going to be a few dozens lines of code that only runs once when the hypervisor starts.

Paolo


Re: [RISC-V] [tech-tee] The proposal of sPMP

Nick Kossifidis
 

Στις 2021-04-19 01:43, Andrew Waterman έγραψε:

I'm going to push back against the proposal to allocate new cause values for sPMP faults. Allocating new cause values has knock-on effects and incremental costs throughout the architecture (with respect to virtualization and delegation, in particular), and so the bar for adding new ones needs to be set high.
Many of us do not believe that composing sPMP and paging is an essential use case to support--and, in fact, some of us would prefer the architectural economy of disallowing their composition. Even if we do support it, software has sufficient information to distinguish sPMP faults from page faults. The process is indeed cumbersome, as y'all have discussed. But it need not be a performance sink--first of all, because this isn't a common case, and second, because the checks can be performed almost entirely off the critical path. (The sPMP checks only need to be performed if the paging subsystem determines the fault shouldn't have occurred--similar to Linux's existing handling of spurious page faults due to lazy shootdowns on upgrades.)
Right now a system without MMU or with satp set to bare mode, will raise an access fault regardless of PMP/ePMP being active, and that access fault may be handled by M-mode or delegated to S-mode as-is through medeleg. If sPMP is present the same system will get an access fault if sPMP is disabled and a page fault if sPMP is active, not only this is inconsistent, it also doesn't make sense to return a page fault when paging is disabled or even unavailable. Even if we don't use sPMP together with MMU the proposal of raising page faults on sPMP failures is a bit off. I believe we should either treat sPMP in the same way as PMP/ePMP and trigger access faults since we are dealing with physical memory, or treat access faults from S-mode in the same way regardless of sPMP. If we decide to treat access faults from S-mode as page faults so that we can delegate them all together to S-mode through medeleg, I'd expect to be able to do this regardless of sPMP being active.

Regards,
Nick


Re: [RISC-V] [tech-tee] The proposal of sPMP

Jonathan Behrens <behrensj@...>
 

How about sPMP is only used if satp.MODE=BARE or virtualization is enabled and hgatp.MODE=BARE? That would enable the trusted hypervisor case, while disallowing an S-mode operating system from enabling both paging and sPMP at the same time.

Jonathan


On Mon, Apr 19, 2021 at 3:24 PM Nick Kossifidis via lists.riscv.org <mick=ics.forth.gr@...> wrote:
Στις 2021-04-19 17:39, Bill Huffman έγραψε:

> I would also rather disallow composing sPMP and paging.  It seems an
> extra complexity for very little benefit.  The argument I understand
> for sPMP is a poor man's paging.  I don't know an argument for having
> both active at the same time.
>
> Bill
>

A scenario we discussed at some point was a trusted hypervisor running
on HS mode, with e.g. Linux and a trusted service running on VS mode.
The trusted hypervisor is usually very small/simple and may not use
paging, so hgatp will be set to bare and it'll fallback to PMP/ePMP as
the current hypervisor spec mandates. With sPMP the hypervisor will be
able to configure its own regions and also isolate Linux from the
trusted service, without going through M-mode using PMP/ePMP, this
allows for a much more flexible / clean implementation. In other words
we can use sPMP as a poor man's paging for HS mode and still use paging
for VS mode, in which case when operating on VS mode both MMU and sPMP
will be active. Such scenarios by the way (with small trusted
hypervisors) are commonly used in mobile phones.

Regards,
Nick






Re: [RISC-V] [tech-tee] The proposal of sPMP

Nick Kossifidis
 

Στις 2021-04-19 17:39, Bill Huffman έγραψε:

I would also rather disallow composing sPMP and paging. It seems an extra complexity for very little benefit. The argument I understand for sPMP is a poor man's paging. I don't know an argument for having both active at the same time.
Bill
A scenario we discussed at some point was a trusted hypervisor running on HS mode, with e.g. Linux and a trusted service running on VS mode. The trusted hypervisor is usually very small/simple and may not use paging, so hgatp will be set to bare and it'll fallback to PMP/ePMP as the current hypervisor spec mandates. With sPMP the hypervisor will be able to configure its own regions and also isolate Linux from the trusted service, without going through M-mode using PMP/ePMP, this allows for a much more flexible / clean implementation. In other words we can use sPMP as a poor man's paging for HS mode and still use paging for VS mode, in which case when operating on VS mode both MMU and sPMP will be active. Such scenarios by the way (with small trusted hypervisors) are commonly used in mobile phones.

Regards,
Nick


Re: [RISC-V] [tech-tee] The proposal of sPMP

Bill Huffman
 

I would also rather disallow composing sPMP and paging.  It seems an extra complexity for very little benefit.  The argument I understand for sPMP is a poor man’s paging.  I don’t know an argument for having both active at the same time.

 

      Bill

 

From: tech-tee@... <tech-tee@...> On Behalf Of Andrew Waterman
Sent: Sunday, April 18, 2021 6:43 PM
To: bichengyang@...
Cc: tech-privileged@...; tech-tee@...
Subject: Re: [RISC-V] [tech-tee] The proposal of sPMP

 

EXTERNAL MAIL

I'm going to push back against the proposal to allocate new cause values for sPMP faults.  Allocating new cause values has knock-on effects and incremental costs throughout the architecture (with respect to virtualization and delegation, in particular), and so the bar for adding new ones needs to be set high.

 

Many of us do not believe that composing sPMP and paging is an essential use case to support--and, in fact, some of us would prefer the architectural economy of disallowing their composition.  Even if we do support it, software has sufficient information to distinguish sPMP faults from page faults.  The process is indeed cumbersome, as y'all have discussed.  But it need not be a performance sink--first of all, because this isn't a common case, and second, because the checks can be performed almost entirely off the critical path.  (The sPMP checks only need to be performed if the paging subsystem determines the fault shouldn't have occurred--similar to Linux's existing handling of spurious page faults due to lazy shootdowns on upgrades.)

 

 

On Thu, Apr 15, 2021 at 5:43 AM <bichengyang@...> wrote:

Hi privileged group,

The TEE group are proposing the sPMP mechanism for S-mode physical memory protection. (As linked below)

The TEE group discusses the proposal for quite a while, and we believe that to handle faults generated by sPMP graciously, add three new exception codes for sPMP seems to be reasonable.

sPMP follows the strategy that uses different exception codes for different cases. Currently, sPMP will generate load/store/instruction sPMP faults for memory load, memory store and instruction fetch, respectively.

Since we want to delegate sPMP fault to S-mode rather than handle it in M-mode as PMP did, we wonder whether it is possible to use three bits in the medeleg register.

Please refer to section 2.5 of the sPMP proposal.

Link to the sPMP proposal:
https://docs.google.com/document/d/1x7esOSBFfpcbDHaRPpe5NEWmav1_8der_nB25Hd5hqs/edit#heading=h.rdbq3ygwk878

Best, 
Bicheng


Re: [RISC-V] [tech-tee] The proposal of sPMP

Andrew Waterman
 

I'm going to push back against the proposal to allocate new cause values for sPMP faults.  Allocating new cause values has knock-on effects and incremental costs throughout the architecture (with respect to virtualization and delegation, in particular), and so the bar for adding new ones needs to be set high.

Many of us do not believe that composing sPMP and paging is an essential use case to support--and, in fact, some of us would prefer the architectural economy of disallowing their composition.  Even if we do support it, software has sufficient information to distinguish sPMP faults from page faults.  The process is indeed cumbersome, as y'all have discussed.  But it need not be a performance sink--first of all, because this isn't a common case, and second, because the checks can be performed almost entirely off the critical path.  (The sPMP checks only need to be performed if the paging subsystem determines the fault shouldn't have occurred--similar to Linux's existing handling of spurious page faults due to lazy shootdowns on upgrades.)


On Thu, Apr 15, 2021 at 5:43 AM <bichengyang@...> wrote:
Hi privileged group,

The TEE group are proposing the sPMP mechanism for S-mode physical memory protection. (As linked below)

The TEE group discusses the proposal for quite a while, and we believe that to handle faults generated by sPMP graciously, add three new exception codes for sPMP seems to be reasonable.

sPMP follows the strategy that uses different exception codes for different cases. Currently, sPMP will generate load/store/instruction sPMP faults for memory load, memory store and instruction fetch, respectively.

Since we want to delegate sPMP fault to S-mode rather than handle it in M-mode as PMP did, we wonder whether it is possible to use three bits in the medeleg register.

Please refer to section 2.5 of the sPMP proposal.

Link to the sPMP proposal:
https://docs.google.com/document/d/1x7esOSBFfpcbDHaRPpe5NEWmav1_8der_nB25Hd5hqs/edit#heading=h.rdbq3ygwk878

Best, 
Bicheng


The proposal of sPMP

bichengyang@...
 

Hi privileged group,

The TEE group are proposing the sPMP mechanism for S-mode physical memory protection. (As linked below)

The TEE group discusses the proposal for quite a while, and we believe that to handle faults generated by sPMP graciously, add three new exception codes for sPMP seems to be reasonable.

sPMP follows the strategy that uses different exception codes for different cases. Currently, sPMP will generate load/store/instruction sPMP faults for memory load, memory store and instruction fetch, respectively.

Since we want to delegate sPMP fault to S-mode rather than handle it in M-mode as PMP did, we wonder whether it is possible to use three bits in the medeleg register.

Please refer to section 2.5 of the sPMP proposal.

Link to the sPMP proposal:
https://docs.google.com/document/d/1x7esOSBFfpcbDHaRPpe5NEWmav1_8der_nB25Hd5hqs/edit#heading=h.rdbq3ygwk878

Best, 
Bicheng


Re: Interrupts in RV32I / RV32E systems

Greg Favor
 

On Thu, Apr 8, 2021 at 2:35 PM Nagendra Gulur <nagendra.gd@...> wrote:
3. Is the CLIC spec on github intended to become a part of the body of RISC-V specifications?

Yes.  For more info (and your other questions) you should post to the Fast Interrupts TG at tech-fast-int@....

Greg


Interrupts in RV32I / RV32E systems

Nagendra Gulur
 

My apologies if this topic was discussed and archived. I did search but mostly came across Unix platform style discussions on interrupt support. But my interest here is mostly around RTOS-based low-end, low-power 32-bit MCUs built with RV32I/RV32E class cores.

In these MCUs, fast save/restore before/after interrupts is essential for both real-time performance and power. I am looking at some guidance in this regard as to what the architecture specification outlines. From reading the unprivileged and privileged specs, I inferred that the hardware would need to save all caller-saved registers to the stack before invoking the interrupt service routine  (plus mcause etc). Is this correct? This is not spelt out as a requirement of the EE or the hardware but it does show up in various search results that this act of saving caller-saved registers is C-ABI compatible. At the same time, I came across the fast interrupt spec on github that describes the CLIC and also mentions C-ABI.

So .. I guess the questions are:

1. What is a minimum set of state to be saved to be RISC-V compliant?
2. If caller-saved registers are not saved, then we will not be C-ABI compatible. Does this potentially create a SW ecosystem fragmentation where some RV32 vendors support C-ABI compatible interrupts and others do not?  
3. Is the CLIC spec on github intended to become a part of the body of RISC-V specifications?

Thanks
Nagendra


Re: Can the ratified ISA be modified?

Andrew Waterman
 


On Wed, Apr 7, 2021 at 8:14 PM <merlew4n6@...> wrote:
I found that the manual in the ratified state that I downloaded did not match the code that I viewed.The main relevant command is HFENCE.GVMA. Its encodings has been changed. Will there be machines with two different instruction encodings in the future? How does the software detect the encoding of this instruction.
 
main modify: HFENCE.GVMA change encode from 0xa2000073 to 0x62000073

Related manuals:[Ratified Handbook]  [Draft Handbook]


Can the ratified ISA be modified?

merle w
 

I found that the manual in the ratified state that I downloaded did not match the code that I viewed.The main relevant command is HFENCE.GVMA. Its encodings has been changed. Will there be machines with two different instruction encodings in the future? How does the software detect the encoding of this instruction.
 
main modify: HFENCE.GVMA change encode from 0xa2000073 to 0x62000073

Related manuals:[Ratified Handbook]  [Draft Handbook]


rf sv64 - bit virtual address space - ALL 64 bits

swallach
 

just to comment.

in the sigHPC working group we will begin to think about a true 64 bit address space (at a minimum). meaning ALL  64 bits have a meaning.

at BSC we are working on such a system.

in the past,  an exascale of performance matched up with an Exabyte of  storage. (one for one).

 i was personally involved with many projects of this type. 

today,  subject to cost and power this metric may not be attainable,  perhaps.  (typical 30 Megwatts Max power)

in any case,  an exabyte of physical storage requires,  for a 60 bit physical address, a 48 bit PPN.  in the current definition of sv57 this can not be defined (for a continuous 48 but field).   but that is ok,  sv57 is sv57. (sv57k).

so,  going forward, some of the characteristics of a TBD sv64 would be

.a true 64 bit virtual address space (no sign extensions)
.support of a PCAS reference model (needed for efficient implementations of UPC and CHAPEL)
.a PPN of a least 48 bits,  but preferably, 52 bits (thus 52+12 =  64)
.a 32 bit ASID
.a more contemporary security model
.100,000’s of nodes (or more). 

be safe






WARNING / LEGAL TEXT: This message is intended only for the use of the individual or entity to which it is addressed and may contain information which is privileged, confidential, proprietary, or exempt from disclosure under applicable law. If you are not the intended recipient or the person responsible for delivering the message to the intended recipient, you are strictly prohibited from disclosing, distributing, copying, or in any way using this message. If you have received this communication in error, please notify the sender and destroy and delete any copies you may have received.

http://www.bsc.es/disclaimer


Re: Correspondence between hedeleg and medeleg writeable bits?

Richard Trauben
 

Hi folks,

Noone wants to have incompatible unverifiable architecture
inplementations.

i recommend  that the specification contain a set of standard profile
string names so architectural compliance verification suites and system software builds use these profiles stringnames to define binary 
“#ifdef $profile”
avs pass/fail criteria to validate 
implementations
are compliant with profile rqmts.

Cheers,
Richard

addendum:

if the number of profiles (and associated effort to define their  avs) explodes,
the profile will be
$vendor$implementation resulting in an ecosystem where very little interoperates.


On Mar 23, 2021, at 10:53 PM, Scott Johnson <scott.johnson@...> wrote:

The spec has very strict requirements on which bits of hedeleg must be writable. (medeleg, not so much.) See Table 5.2: except for bit 10 (ecall from VS-mode) there is no implementation flexibility on the bits of hedeleg.



On Tue, Mar 23, 2021 at 09:58 PM, Greg Favor wrote:
On Mon, Mar 8, 2021 at 1:22 PM James Robinson <jrobinson@...> wrote:
I see that the list of hedeleg writable bits includes bits which are not writable in medeleg in the spike implementation (Illegal Instruction, Load/Store address misaligned, Load/Store/Inst Access Fault).

Is it intended that these bits should be writable even if they are not writable in medeleg, and that the writability the corresponding bits in medeleg remains an implementation choice?

In which case, some exceptions, although writable in hedeleg, will never actually be delegated to VS-mode by the hardware?

Is machine mode software expected (under certain circumstances) to emulate delegation of the exception by setting up the correct state and executing mret?
 
On Wed, Mar 10, 2021 at 3:23 AM James Robinson <jrobinson@...> wrote:
Pinging to see if any of the architects can chime in to clarify whether H-extension cores are supposed to have bits which are writable in hedeleg but not medeleg, as per the current spec?
 
 
I can't speak to how Spike's modeling of the architecture is intended to relate to all the functionality and options that are allowed within the full architecture.  (Andrew would be the one to provide useful commentary.)    But the above medeleg implementation in Spike is restricted wrt what is allowed by the architecture, so one should be careful about what inferences about the overall architecture one draws from that.  (Although, for what it's worth, hardwiring the above medeleg bits is reasonable and not surprising.)
 
But from an arch spec perspective:
 
What M-mode is "expected" to do for exceptions from lower privilege modes that it receives and doesn't delegate down, is a software choice (and not something to be specified by the architecture).  RISC-V architecture just tries to provide the flexibility to address a wide range of systems designs and software environments.
 
Within the few constraints specified for medeleg, bits can be implemented as hardwired or writeable (although for many systems there are sensible/preferable choices even though the arch spec doesn't require them).  Ditto for hedeleg.  And the two are architecturally orthogonal.  Although, of course, if a medeleg bit is hardwired to 0 in particular, then the implementation of the corresponding hedeleg bit is a don't care.  And an implementation could choose to support that, but probably would also hardwire the hedeleg bit to 0.
 
Ultimately this is all primarily a software architecture issue, and in a complete system M-mode and S/HS-mode software (along with the underlying hardware platform) have to behave in a coordinated manner.  Which will be different for different class systems.
 
Greg
 


Re: Correspondence between hedeleg and medeleg writeable bits?

Scott Johnson
 

The spec has very strict requirements on which bits of hedeleg must be writable. (medeleg, not so much.) See Table 5.2: except for bit 10 (ecall from VS-mode) there is no implementation flexibility on the bits of hedeleg.



On Tue, Mar 23, 2021 at 09:58 PM, Greg Favor wrote:
On Mon, Mar 8, 2021 at 1:22 PM James Robinson <jrobinson@...> wrote:
I see that the list of hedeleg writable bits includes bits which are not writable in medeleg in the spike implementation (Illegal Instruction, Load/Store address misaligned, Load/Store/Inst Access Fault).

Is it intended that these bits should be writable even if they are not writable in medeleg, and that the writability the corresponding bits in medeleg remains an implementation choice?

In which case, some exceptions, although writable in hedeleg, will never actually be delegated to VS-mode by the hardware?

Is machine mode software expected (under certain circumstances) to emulate delegation of the exception by setting up the correct state and executing mret?
 
On Wed, Mar 10, 2021 at 3:23 AM James Robinson <jrobinson@...> wrote:
Pinging to see if any of the architects can chime in to clarify whether H-extension cores are supposed to have bits which are writable in hedeleg but not medeleg, as per the current spec?
 
 
I can't speak to how Spike's modeling of the architecture is intended to relate to all the functionality and options that are allowed within the full architecture.  (Andrew would be the one to provide useful commentary.)    But the above medeleg implementation in Spike is restricted wrt what is allowed by the architecture, so one should be careful about what inferences about the overall architecture one draws from that.  (Although, for what it's worth, hardwiring the above medeleg bits is reasonable and not surprising.)
 
But from an arch spec perspective:
 
What M-mode is "expected" to do for exceptions from lower privilege modes that it receives and doesn't delegate down, is a software choice (and not something to be specified by the architecture).  RISC-V architecture just tries to provide the flexibility to address a wide range of systems designs and software environments.
 
Within the few constraints specified for medeleg, bits can be implemented as hardwired or writeable (although for many systems there are sensible/preferable choices even though the arch spec doesn't require them).  Ditto for hedeleg.  And the two are architecturally orthogonal.  Although, of course, if a medeleg bit is hardwired to 0 in particular, then the implementation of the corresponding hedeleg bit is a don't care.  And an implementation could choose to support that, but probably would also hardwire the hedeleg bit to 0.
 
Ultimately this is all primarily a software architecture issue, and in a complete system M-mode and S/HS-mode software (along with the underlying hardware platform) have to behave in a coordinated manner.  Which will be different for different class systems.
 
Greg
 


Re: Correspondence between hedeleg and medeleg writeable bits?

Greg Favor
 

On Mon, Mar 8, 2021 at 1:22 PM James Robinson <jrobinson@...> wrote:
I see that the list of hedeleg writable bits includes bits which are not writable in medeleg in the spike implementation (Illegal Instruction, Load/Store address misaligned, Load/Store/Inst Access Fault).

Is it intended that these bits should be writable even if they are not writable in medeleg, and that the writability the corresponding bits in medeleg remains an implementation choice?

In which case, some exceptions, although writable in hedeleg, will never actually be delegated to VS-mode by the hardware?

Is machine mode software expected (under certain circumstances) to emulate delegation of the exception by setting up the correct state and executing mret?

On Wed, Mar 10, 2021 at 3:23 AM James Robinson <jrobinson@...> wrote:
Pinging to see if any of the architects can chime in to clarify whether H-extension cores are supposed to have bits which are writable in hedeleg but not medeleg, as per the current spec?


I can't speak to how Spike's modeling of the architecture is intended to relate to all the functionality and options that are allowed within the full architecture.  (Andrew would be the one to provide useful commentary.)    But the above medeleg implementation in Spike is restricted wrt what is allowed by the architecture, so one should be careful about what inferences about the overall architecture one draws from that.  (Although, for what it's worth, hardwiring the above medeleg bits is reasonable and not surprising.)

But from an arch spec perspective:

What M-mode is "expected" to do for exceptions from lower privilege modes that it receives and doesn't delegate down, is a software choice (and not something to be specified by the architecture).  RISC-V architecture just tries to provide the flexibility to address a wide range of systems designs and software environments.

Within the few constraints specified for medeleg, bits can be implemented as hardwired or writeable (although for many systems there are sensible/preferable choices even though the arch spec doesn't require them).  Ditto for hedeleg.  And the two are architecturally orthogonal.  Although, of course, if a medeleg bit is hardwired to 0 in particular, then the implementation of the corresponding hedeleg bit is a don't care.  And an implementation could choose to support that, but probably would also hardwire the hedeleg bit to 0.

Ultimately this is all primarily a software architecture issue, and in a complete system M-mode and S/HS-mode software (along with the underlying hardware platform) have to behave in a coordinated manner.  Which will be different for different class systems.

Greg


Re: Hypervisor interrupt enables

Scott Johnson
 

Filed a spec issue since I don't think this discussion has resolved any of the questions.


Re: Hypervisor interrupt enables

Siqi Zhao
 

In the KVM case, the hypervisor / linux kernel disables (HS-mode) interrupt globally before switching to VS-mode. However, when an HS-mode interrupt occurs, e.g. a HS-mode timer interrupt, the hart performs a two-step operation: first it switches back to HS-mode, and begins to execute the execution handler at stvec, at this point the HS-mode interrupt is still disabled. Second, the handler at some point later enables HS-mode interrupt, now the hart takes the timer interrupt.

I always understand there is a mandatory mode switch dictated by the fact that HS-mode is more privileged than VS-mode. This is separate from the evaluation of interrupt pending status when the mode switch has already completed.

721 - 740 of 1276