Date   

Re: Quetion about execution environment and platform-specific interrupt controller

Greg Favor
 

On Sun, Nov 20, 2022 at 3:15 AM Oscar Jupp <jupposcar@...> wrote:
Dear architect,
The privileged ISA said:
 “Bits sip.STIP and sie.STIE are the interrupt-pending and interrupt-enable bits for supervisorlevel timer interrupts. If implemented, STIP is read-only in sip, and is set and cleared by the execution environment
Bits sip.SSIP and sie.SSIE are the interrupt-pending and interrupt-enable bits for supervisorlevel software interrupts. If implemented, SSIP is writable in sip and may also be set to 1 by a platform-specific interrupt controller.”
What does “execution environment“ refer to in the description of sip.STIP?

See Priv section 1.1 and Unpriv section 1.2 for description.

Greg




Quetion about execution environment and platform-specific interrupt controller

Oscar Jupp
 

Dear architect,
The privileged ISA said:
 “Bits sip.STIP and sie.STIE are the interrupt-pending and interrupt-enable bits for supervisorlevel timer interrupts. If implemented, STIP is read-only in sip, and is set and cleared by the execution environment
Bits sip.SSIP and sie.SSIE are the interrupt-pending and interrupt-enable bits for supervisorlevel software interrupts. If implemented, SSIP is writable in sip and may also be set to 1 by a platform-specific interrupt controller.”
What does “execution environment“ refer to in the description of sip.STIP? Is the M-level software? Or is it a pure hardware platform like an interrupt controller? What does "platform-specific interrupt controller" refer to in the description of sip.SSIP? I think that inter-core interrupts are implemented through bus configuration memory-mapped registers? Why does it need an interrupt controller?

Regards,
Oscar Jupp


Re: Meaning of Implemented in Sstc specification

Greg Favor
 

On Fri, Nov 18, 2022 at 7:25 AM <kenney@...> wrote:
The Sstc specification has this text (referring to whether STIP is writable):

If the stimecmp register is not implemented, STIP is writable in mip, and may be written by M-mode software to deliver timer interrupts to S-mode. If the stimecmp (supervisor-mode timer compare) register is implemented, STIP is read-only in mip and reflects the supervisor-level timer interrupt signal resulting from stimecmp.

In the context of the overall Sstc spec, this text is correct in stating the baseline behavior when Sstc is implemented or not  (and is precisely correct when Sstc is not implemented).  And then the Environment Config Support section provides a more nuanced spec of what happens when STCE=0 - which isn't simply the preceding "not implemented" text.  Instead, the more precise and complete spec is that:

When STCE in menvcfg is zero, an attempt to access stimecmp or vstimecmp in a mode other than M-mode raises an illegal instruction exception, STCE in henvcfg is read-only zero, and STIP in mip and sip reverts to its defined behavior as if this extension is not implemented.

Can you please clarify what is meant by implemented here? Andrew Waterman pointed me at a statement in the Privileged Specification that indicated that implemented implicitly meant implemented and enabled, but that doesn't seem fully relevant here, for the reason that if the Sstc extension is present then stimecmp is always accessible at M-mode, so in some sense this extension is always enabled.

This is why the first excerpted text above about when Sstc is not implemented, does not also apply to when Sstc is implemented and disabled.
 
It feels that, for software backwards-compatibility, STIP should be writeable by M-mode if menvcfg.STCE=0 and read-only if menvcfg.STCE=1, but I am unsure whether this is the intention.

I think the second excerpted text above is pretty direct and clear as to the intention (which matches what one would want for backwards-compatibility).

Greg
 


Meaning of Implemented in Sstc specification

kenney@...
 

The Sstc specification has this text (referring to whether STIP is writable):

If the stimecmp register is not implemented, STIP is writable in mip, and may be written by M-mode software to deliver timer interrupts to S-mode. If the stimecmp (supervisor-mode timer compare) register is implemented, STIP is read-only in mip and reflects the supervisor-level timer interrupt signal resulting from stimecmp.

Can you please clarify what is meant by implemented here? Andrew Waterman pointed me at a statement in the Privileged Specification that indicated that implemented implicitly meant implemented and enabled, but that doesn't seem fully relevant here, for the reason that if the Sstc extension is present then stimecmp is always accessible at M-mode, so in some sense this extension is always enabled.

It feels that, for software backwards-compatibility, STIP should be writeable by M-mode if menvcfg.STCE=0 and read-only if menvcfg.STCE=1, but I am unsure whether this is the intention.

A similar clarification is needed for VSTIP, when the Hypervisor is implemented.

Thanks.


Question about privilege

Oscar Jupp
 

Dear architect,
I don't know the difference between illegal instruction exception and virtual instruction exception.
For example:
The CSR number of sstatus is 0x100,The CSR number of vsstatus is 0x200.
Q1:When the privilege level is VU, should the CSR instruction access the register numbered 0x100 produce illegal instruction exception or virtual instruction exception? 
Q2:When the privilege level is U, should the CSR instruction access the register numbered 0x200 produce illegal instruction exception or virtual instruction exception? 

Regards,
Oscar Jupp



Re: Question about CSR hedeleg and hideleg

Oscar Jupp
 

Dear architect,
Similarly, the hardwired bits prevent it from sending M interrupts to S mode. It is right?

Regards,
Oscar Jupp


---- Replied Message ----
From Paul Donahue<pdonahue@...>
Date 11/18/2022 03:13
To jupposcar<jupposcar@...>
Cc tech-privileged@...<tech-privileged@...>
Subject Re: [RISC-V] [tech-privileged] Question about CSR hedeleg and hideleg
The idea is that interrupts should be handled in the mode they target or a more privileged mode, not a less privileged mode.  The hypervisor can optionally send VS interrupts to VS mode but the hardwired bits prevent it from sending M or S interrupts to VS mode.


-Paul


On Thu, Nov 17, 2022 at 4:22 AM jupposcar <jupposcar@...> wrote:
Dear Paul Donahue,
Thank you very much for your reply!
I have another question about hideleg。The privileged ISA said: “Among bits 15:0 of hideleg, bits 10, 6, and 2 (corresponding to the standard VS-level interrupts) are writable, and bits 12, 9, 5, and 1 (corresponding to the standard S-level interrupts) are read-only zeros.” 
How about the other bits? Bits 11,7, and 3 (corresponding to the standard M-level interrupts) are read-only zeros? Why?

Regards,
Oscar Jupp


---- Replied Message ----
From Paul Donahue<pdonahue@...>
Date 11/17/2022 01:39
To Oscar Jupp<jupposcar@...>
Cc <tech-privileged@...>
Subject Re: [RISC-V] [tech-privileged] Question about CSR hedeleg and hideleg
For instance, page faults should normally be delegated to the operating system that manages the page tables rather than handling it in a higher mode which doesn't know anything about the OS's memory management.  So if page tables are managed in S/HS, you don't want to handle page faults in M mode and you use medeleg to do the delegation.  Similarly, if a guest (VU or VS) gets a page fault then you want to use hedeleg to delegate to the guest OS which is managing VS-stage page tables.


-Paul


On Wed, Nov 16, 2022 at 3:28 AM Oscar Jupp <jupposcar@...> wrote:
To whom it may concern,
I have a question about CSR hedeleg and hideleg.
The ISA  Manual said: "The hedeleg and hideleg CSRs allow these traps to be further delegated to a VS-mode guest." 
I would like to know in what scenario or under what requirements, it is necessary to delegate the interrupt or exception to the VS mode? What would be the impact of making all bits of these two CSRs read-only zeros?
Any help would be greatly appreciated!
Regards
Oscar Jupp


Re: Question about CSR hedeleg and hideleg

Oscar Jupp
 

Dear architect,
Thanks! I learned a lot from you.
I used to think that mip is used to indicate the summary of interrupts that need to be responded in M state, sip is used to indicate the summary of interrupts that need to be responded in S state, and vsip is used to indicate the summary of interrupts that need to be responded in VS state. It seems I misunderstood.
Regards,
Oscar Jupp


---- Replied Message ----
From Scott Johnson<scott.johnson@...>
Date 11/18/2022 11:37
To Oscar Jupp<jupposcar@...>
Cc tech-privileged@...<tech-privileged@...>
Subject Re: [RISC-V] [tech-privileged] Question about CSR hedeleg and hideleg
No.

Assuming bit 10 of hideleg is one, vsip.SEIP is an alias of hip.VSEIP.

mip.VSEIP is an alias of hip.VSEIP.

Bit 10 in mideleg is read-only one, so mip.VSEIP is visible as sip.VSEIP.

Therefore both sip.VSEIP and mip.VSEIP will be 1.

An implementation really only needs to have one set of state for mip and that will cover all the other *ip CSRs, which are all views into that one set of bits.


On Nov 17, 2022, at 9:21 PM, Oscar Jupp <jupposcar@...> wrote:

Dear Paul Donahue,
Thank you very much.
I would like to ask another question.
The VS level external interrupt has been delegated to the VS level (That is, mideleg[10] = 1 and hideleg[10] = 1). When an VS level external interrupt comes in, only vsip.SEIP will be set. The sip.VSEIP and mip.VSEIP are both 0. Is it right?

Regards,
Oscar Jupp

---- Replied Message ----
From Paul Donahue<pdonahue@...>
Date 11/18/2022 03:13
To jupposcar<jupposcar@...>
Cc tech-privileged@...<tech-privileged@...>
Subject Re: [RISC-V] [tech-privileged] Question about CSR hedeleg and hideleg
The idea is that interrupts should be handled in the mode they target or a more privileged mode, not a less privileged mode.  The hypervisor can optionally send VS interrupts to VS mode but the hardwired bits prevent it from sending M or S interrupts to VS mode.


-Paul


On Thu, Nov 17, 2022 at 4:22 AM jupposcar <jupposcar@...> wrote:
Dear Paul Donahue,
Thank you very much for your reply!
I have another question about hideleg。The privileged ISA said: “Among bits 15:0 of hideleg, bits 10, 6, and 2 (corresponding to the standard VS-level interrupts) are writable, and bits 12, 9, 5, and 1 (corresponding to the standard S-level interrupts) are read-only zeros.” 
How about the other bits? Bits 11,7, and 3 (corresponding to the standard M-level interrupts) are read-only zeros? Why?

Regards,
Oscar Jupp


---- Replied Message ----
From Paul Donahue<pdonahue@...>
Date 11/17/2022 01:39
To Oscar Jupp<jupposcar@...>
Cc <tech-privileged@...>
Subject Re: [RISC-V] [tech-privileged] Question about CSR hedeleg and hideleg
For instance, page faults should normally be delegated to the operating system that manages the page tables rather than handling it in a higher mode which doesn't know anything about the OS's memory management.  So if page tables are managed in S/HS, you don't want to handle page faults in M mode and you use medeleg to do the delegation.  Similarly, if a guest (VU or VS) gets a page fault then you want to use hedeleg to delegate to the guest OS which is managing VS-stage page tables.


-Paul


On Wed, Nov 16, 2022 at 3:28 AM Oscar Jupp <jupposcar@...> wrote:
To whom it may concern,
I have a question about CSR hedeleg and hideleg.
The ISA  Manual said: "The hedeleg and hideleg CSRs allow these traps to be further delegated to a VS-mode guest." 
I would like to know in what scenario or under what requirements, it is necessary to delegate the interrupt or exception to the VS mode? What would be the impact of making all bits of these two CSRs read-only zeros?
Any help would be greatly appreciated!
Regards
Oscar Jupp




Re: Question about CSR hedeleg and hideleg

Scott Johnson
 

No.

Assuming bit 10 of hideleg is one, vsip.SEIP is an alias of hip.VSEIP.

mip.VSEIP is an alias of hip.VSEIP.

Bit 10 in mideleg is read-only one, so mip.VSEIP is visible as sip.VSEIP.

Therefore both sip.VSEIP and mip.VSEIP will be 1.

An implementation really only needs to have one set of state for mip and that will cover all the other *ip CSRs, which are all views into that one set of bits.


On Nov 17, 2022, at 9:21 PM, Oscar Jupp <jupposcar@...> wrote:

Dear Paul Donahue,
Thank you very much.
I would like to ask another question.
The VS level external interrupt has been delegated to the VS level (That is, mideleg[10] = 1 and hideleg[10] = 1). When an VS level external interrupt comes in, only vsip.SEIP will be set. The sip.VSEIP and mip.VSEIP are both 0. Is it right?

Regards,
Oscar Jupp

---- Replied Message ----
From Paul Donahue<pdonahue@...>
Date 11/18/2022 03:13
To jupposcar<jupposcar@...>
Cc tech-privileged@...<tech-privileged@...>
Subject Re: [RISC-V] [tech-privileged] Question about CSR hedeleg and hideleg
The idea is that interrupts should be handled in the mode they target or a more privileged mode, not a less privileged mode.  The hypervisor can optionally send VS interrupts to VS mode but the hardwired bits prevent it from sending M or S interrupts to VS mode.


-Paul


On Thu, Nov 17, 2022 at 4:22 AM jupposcar <jupposcar@...> wrote:
Dear Paul Donahue,
Thank you very much for your reply!
I have another question about hideleg。The privileged ISA said: “Among bits 15:0 of hideleg, bits 10, 6, and 2 (corresponding to the standard VS-level interrupts) are writable, and bits 12, 9, 5, and 1 (corresponding to the standard S-level interrupts) are read-only zeros.” 
How about the other bits? Bits 11,7, and 3 (corresponding to the standard M-level interrupts) are read-only zeros? Why?

Regards,
Oscar Jupp


---- Replied Message ----
From Paul Donahue<pdonahue@...>
Date 11/17/2022 01:39
To Oscar Jupp<jupposcar@...>
Cc <tech-privileged@...>
Subject Re: [RISC-V] [tech-privileged] Question about CSR hedeleg and hideleg
For instance, page faults should normally be delegated to the operating system that manages the page tables rather than handling it in a higher mode which doesn't know anything about the OS's memory management.  So if page tables are managed in S/HS, you don't want to handle page faults in M mode and you use medeleg to do the delegation.  Similarly, if a guest (VU or VS) gets a page fault then you want to use hedeleg to delegate to the guest OS which is managing VS-stage page tables.


-Paul


On Wed, Nov 16, 2022 at 3:28 AM Oscar Jupp <jupposcar@...> wrote:
To whom it may concern,
I have a question about CSR hedeleg and hideleg.
The ISA  Manual said: "The hedeleg and hideleg CSRs allow these traps to be further delegated to a VS-mode guest." 
I would like to know in what scenario or under what requirements, it is necessary to delegate the interrupt or exception to the VS mode? What would be the impact of making all bits of these two CSRs read-only zeros?
Any help would be greatly appreciated!
Regards
Oscar Jupp




Re: Question about guest external interrupt

Scott Johnson
 

They are all external interrupts to the physical machine. The hypervisor software will decide which, if any, of these external interrupts should be passed through to which guest OS, and direct the appropriate ones through hardware (if GEILEN>0) or software (if GEILEN=0).

This is explained in the privileged spec under hgeip:

If a RISC-V platform supports placing a physical device under the direct control of a guest OS with

minimal hypervisor intervention (known as pass-through or direct assignment between a virtual machine

and the physical device), then, in such circumstance, interrupts from the device are intended

for a specific virtual machine.



I would imagine the hypervisor software will have some kind of UI or API for the user to associate a particular hardware device with a particular guest OS. This enables higher performance than the alternative of virtualizing every device so they can be shared across all guests.

GEILEN>0 enables this pass-through to be higher performance because it doesn’t require the intervention of the hypervisor software on every single interrupt.



On Nov 17, 2022, at 9:02 PM, jupposcar <jupposcar@...> wrote:

Dear Scott Johnson,
Thank you very much!
You said: “If the hardware has GEILEN=0 then the external interrupt will first go to the hypervisor software, which can pass through the interrupt to the guest by setting `hvip.VSEIP`.”
Do you mean that the hypervisor can distinguish between the external interrupt to the physical machine and external interrupt to the guest?
How does the hypervisor know which interrupt is a external interrupt to the physical machine? Or is it a external interrupt to the guest?

Regards,
Oscar Jupp


Re: Question about CSR hedeleg and hideleg

Oscar Jupp
 

Dear Paul Donahue,
Thank you very much.
I would like to ask another question.
The VS level external interrupt has been delegated to the VS level (That is, mideleg[10] = 1 and hideleg[10] = 1). When an VS level external interrupt comes in, only vsip.SEIP will be set. The sip.VSEIP and mip.VSEIP are both 0. Is it right?

Regards,
Oscar Jupp

---- Replied Message ----
From Paul Donahue<pdonahue@...>
Date 11/18/2022 03:13
To jupposcar<jupposcar@...>
Cc tech-privileged@...<tech-privileged@...>
Subject Re: [RISC-V] [tech-privileged] Question about CSR hedeleg and hideleg
The idea is that interrupts should be handled in the mode they target or a more privileged mode, not a less privileged mode.  The hypervisor can optionally send VS interrupts to VS mode but the hardwired bits prevent it from sending M or S interrupts to VS mode.


-Paul


On Thu, Nov 17, 2022 at 4:22 AM jupposcar <jupposcar@...> wrote:
Dear Paul Donahue,
Thank you very much for your reply!
I have another question about hideleg。The privileged ISA said: “Among bits 15:0 of hideleg, bits 10, 6, and 2 (corresponding to the standard VS-level interrupts) are writable, and bits 12, 9, 5, and 1 (corresponding to the standard S-level interrupts) are read-only zeros.” 
How about the other bits? Bits 11,7, and 3 (corresponding to the standard M-level interrupts) are read-only zeros? Why?

Regards,
Oscar Jupp


---- Replied Message ----
From Paul Donahue<pdonahue@...>
Date 11/17/2022 01:39
To Oscar Jupp<jupposcar@...>
Cc <tech-privileged@...>
Subject Re: [RISC-V] [tech-privileged] Question about CSR hedeleg and hideleg
For instance, page faults should normally be delegated to the operating system that manages the page tables rather than handling it in a higher mode which doesn't know anything about the OS's memory management.  So if page tables are managed in S/HS, you don't want to handle page faults in M mode and you use medeleg to do the delegation.  Similarly, if a guest (VU or VS) gets a page fault then you want to use hedeleg to delegate to the guest OS which is managing VS-stage page tables.


-Paul


On Wed, Nov 16, 2022 at 3:28 AM Oscar Jupp <jupposcar@...> wrote:
To whom it may concern,
I have a question about CSR hedeleg and hideleg.
The ISA  Manual said: "The hedeleg and hideleg CSRs allow these traps to be further delegated to a VS-mode guest." 
I would like to know in what scenario or under what requirements, it is necessary to delegate the interrupt or exception to the VS mode? What would be the impact of making all bits of these two CSRs read-only zeros?
Any help would be greatly appreciated!
Regards
Oscar Jupp


Re: Question about guest external interrupt

Oscar Jupp
 

Dear Scott Johnson,
Thank you very much!
You said: “If the hardware has GEILEN=0 then the external interrupt will first go to the hypervisor software, which can pass through the interrupt to the guest by setting `hvip.VSEIP`.”
Do you mean that the hypervisor can distinguish between the external interrupt to the physical machine and external interrupt to the guest?
How does the hypervisor know which interrupt is a external interrupt to the physical machine? Or is it a external interrupt to the guest?

Regards,
Oscar Jupp


---- Replied Message ----
From Scott Johnson<scott.johnson@...>
Date 11/17/2022 22:56
To <tech-privileged@...>
Subject Re: [RISC-V] [tech-privileged] Question about guest external interrupt
External interrupts are passed through to the guest by setting `hip.VSEIP`, which the guest OS sees as `sip.SEIP`.

The hypervisor software decides which interrupts should be passed through to which guest OS.

If the hardware has GEILEN>0 then the hypervisor software can configure `hstatus.VGEIN` and `hgeie` such that `hip.VSEIP` can be set by the external interrupt directly.

If the hardware has GEILEN=0 then the external interrupt will first go to the hypervisor software, which can pass through the interrupt to the guest by setting `hvip.VSEIP`.

Either way, the guest OS sees the same thing.


Re: Question about CSR hedeleg and hideleg

Paul Donahue
 

The idea is that interrupts should be handled in the mode they target or a more privileged mode, not a less privileged mode.  The hypervisor can optionally send VS interrupts to VS mode but the hardwired bits prevent it from sending M or S interrupts to VS mode.


-Paul


On Thu, Nov 17, 2022 at 4:22 AM jupposcar <jupposcar@...> wrote:
Dear Paul Donahue,
Thank you very much for your reply!
I have another question about hideleg。The privileged ISA said: “Among bits 15:0 of hideleg, bits 10, 6, and 2 (corresponding to the standard VS-level interrupts) are writable, and bits 12, 9, 5, and 1 (corresponding to the standard S-level interrupts) are read-only zeros.” 
How about the other bits? Bits 11,7, and 3 (corresponding to the standard M-level interrupts) are read-only zeros? Why?

Regards,
Oscar Jupp


---- Replied Message ----
From Paul Donahue<pdonahue@...>
Date 11/17/2022 01:39
To Oscar Jupp<jupposcar@...>
Cc <tech-privileged@...>
Subject Re: [RISC-V] [tech-privileged] Question about CSR hedeleg and hideleg
For instance, page faults should normally be delegated to the operating system that manages the page tables rather than handling it in a higher mode which doesn't know anything about the OS's memory management.  So if page tables are managed in S/HS, you don't want to handle page faults in M mode and you use medeleg to do the delegation.  Similarly, if a guest (VU or VS) gets a page fault then you want to use hedeleg to delegate to the guest OS which is managing VS-stage page tables.


-Paul


On Wed, Nov 16, 2022 at 3:28 AM Oscar Jupp <jupposcar@...> wrote:
To whom it may concern,
I have a question about CSR hedeleg and hideleg.
The ISA  Manual said: "The hedeleg and hideleg CSRs allow these traps to be further delegated to a VS-mode guest." 
I would like to know in what scenario or under what requirements, it is necessary to delegate the interrupt or exception to the VS mode? What would be the impact of making all bits of these two CSRs read-only zeros?
Any help would be greatly appreciated!
Regards
Oscar Jupp


Re: Question about guest external interrupt

Scott Johnson
 

External interrupts are passed through to the guest by setting `hip.VSEIP`, which the guest OS sees as `sip.SEIP`.

The hypervisor software decides which interrupts should be passed through to which guest OS.

If the hardware has GEILEN>0 then the hypervisor software can configure `hstatus.VGEIN` and `hgeie` such that `hip.VSEIP` can be set by the external interrupt directly.

If the hardware has GEILEN=0 then the external interrupt will first go to the hypervisor software, which can pass through the interrupt to the guest by setting `hvip.VSEIP`.

Either way, the guest OS sees the same thing.


Re: Question about CSR hedeleg and hideleg

Oscar Jupp
 

Dear Paul Donahue,
Thank you very much for your reply!
I have another question about hideleg。The privileged ISA said: “Among bits 15:0 of hideleg, bits 10, 6, and 2 (corresponding to the standard VS-level interrupts) are writable, and bits 12, 9, 5, and 1 (corresponding to the standard S-level interrupts) are read-only zeros.” 
How about the other bits? Bits 11,7, and 3 (corresponding to the standard M-level interrupts) are read-only zeros? Why?

Regards,
Oscar Jupp


---- Replied Message ----
From Paul Donahue<pdonahue@...>
Date 11/17/2022 01:39
To Oscar Jupp<jupposcar@...>
Cc <tech-privileged@...>
Subject Re: [RISC-V] [tech-privileged] Question about CSR hedeleg and hideleg
For instance, page faults should normally be delegated to the operating system that manages the page tables rather than handling it in a higher mode which doesn't know anything about the OS's memory management.  So if page tables are managed in S/HS, you don't want to handle page faults in M mode and you use medeleg to do the delegation.  Similarly, if a guest (VU or VS) gets a page fault then you want to use hedeleg to delegate to the guest OS which is managing VS-stage page tables.


-Paul


On Wed, Nov 16, 2022 at 3:28 AM Oscar Jupp <jupposcar@...> wrote:
To whom it may concern,
I have a question about CSR hedeleg and hideleg.
The ISA  Manual said: "The hedeleg and hideleg CSRs allow these traps to be further delegated to a VS-mode guest." 
I would like to know in what scenario or under what requirements, it is necessary to delegate the interrupt or exception to the VS mode? What would be the impact of making all bits of these two CSRs read-only zeros?
Any help would be greatly appreciated!
Regards
Oscar Jupp


Re: Question about guest external interrupt

Oscar Jupp
 

Dear Anup Patel,
Thank you very much for your reply.
 I would like to continue to ask: If GEILEN is 0, CSR hgeip and hgeie will always be all zero. Then, hip.SGEIP is always 0. You said: “software (i.e. hypervisor) can still inject external interrupts using hvip CSR. “ But hvip CSR can only make hip.VSSIP, hip.VSTIP and hip.VSEIP raised. It can not make hip.SGEIP be “1”. How does the implement recognize that this is a guest external interrupt.

Regards,
Oscar Jupp


---- Replied Message ----
From Anup Patel<apatel@...>
Date 11/17/2022 11:56
To Oscar Jupp<jupposcar@...>
Cc tech-privileged@...<tech-privileged@...>
Subject Re: [RISC-V] [tech-privileged] Question about guest external interrupt
On Thu, Nov 17, 2022 at 9:07 AM Oscar Jupp <jupposcar@...> wrote:


To whom it may concern,
I have a question about guest external interrupt.
The privileged ISA said: "GEILEN may be zero". If GEILEN is zero, is the implementation unable to receive guest external interrupts at all? Or can it be injected by software means?

If GEILEN is zero then there are no guest external interrupts but
software (i.e. hypervisor) can still inject external interrupts using
hvip CSR. In other words, software-injected external interrupts are
always available to a hypervisor using H-extension.

Regards,
Anup

Any help would be greatly appreciated! Thank you
Regards
Oscar Jupp


Re: Question about guest external interrupt

Anup Patel
 

On Thu, Nov 17, 2022 at 9:07 AM Oscar Jupp <jupposcar@...> wrote:


To whom it may concern,
I have a question about guest external interrupt.
The privileged ISA said: "GEILEN may be zero". If GEILEN is zero, is the implementation unable to receive guest external interrupts at all? Or can it be injected by software means?
If GEILEN is zero then there are no guest external interrupts but
software (i.e. hypervisor) can still inject external interrupts using
hvip CSR. In other words, software-injected external interrupts are
always available to a hypervisor using H-extension.

Regards,
Anup

Any help would be greatly appreciated! Thank you
Regards
Oscar Jupp


Question about guest external interrupt

Oscar Jupp
 


To whom it may concern,
I have a question about guest external interrupt.
The privileged ISA said: "GEILEN may be zero". If GEILEN is zero, is the implementation unable to receive guest external interrupts at all? Or can it be injected by software means?
Any help would be greatly appreciated!
Regards
Oscar Jupp


Re: Question about CSR hedeleg and hideleg

Paul Donahue
 

For instance, page faults should normally be delegated to the operating system that manages the page tables rather than handling it in a higher mode which doesn't know anything about the OS's memory management.  So if page tables are managed in S/HS, you don't want to handle page faults in M mode and you use medeleg to do the delegation.  Similarly, if a guest (VU or VS) gets a page fault then you want to use hedeleg to delegate to the guest OS which is managing VS-stage page tables.


-Paul


On Wed, Nov 16, 2022 at 3:28 AM Oscar Jupp <jupposcar@...> wrote:
To whom it may concern,
I have a question about CSR hedeleg and hideleg.
The ISA  Manual said: "The hedeleg and hideleg CSRs allow these traps to be further delegated to a VS-mode guest." 
I would like to know in what scenario or under what requirements, it is necessary to delegate the interrupt or exception to the VS mode? What would be the impact of making all bits of these two CSRs read-only zeros?
Any help would be greatly appreciated!
Regards
Oscar Jupp


Question about CSR hedeleg and hideleg

Oscar Jupp
 

To whom it may concern,
I have a question about CSR hedeleg and hideleg.
The ISA  Manual said: "The hedeleg and hideleg CSRs allow these traps to be further delegated to a VS-mode guest." 
I would like to know in what scenario or under what requirements, it is necessary to delegate the interrupt or exception to the VS mode? What would be the impact of making all bits of these two CSRs read-only zeros?
Any help would be greatly appreciated!
Regards
Oscar Jupp


AR (Architecture Review) Committee minutes for 11/8

Greg Favor
 

We (the AR Committee) will be posting minutes of our (roughly) weekly meetings to discuss ISA issues that have been raised recently to the committee's attention, and to review RV arch extensions that have been submitted for official AR (or for prelim review).  Here are this week's minutes.

Minutes from AR Committee meeting on 11/8/22
  • Discussed recent Zcmt software-related issues.  Confirmed that Zcmt is incompatible with the RVA profile, since RVA mandates Zcd, which conflicts with Zcmt.  Hence "missing" software support on application-class Linux systems is a moot issue.  Similarly, AR is also not convinced as to the need for Zcmt to support position independent code.  A much fuller response on the latter has been posted on tech-code-size to further the discussion.
  • Svadu regarding "cacheable main memory" requirement
    The current spec requires that page tables be in "cacheable main memory" - which is imprecise and not quite right as far as the required PMA attributes.  The requirement has been clarified and resolved to be that page tables need to be in PMA regions that have the RsrvEventual attribute (so that hart software can also make compare-and-swap style atomic changes to PTEs using LR/SC concurrently with hardware doing atomic A&D updates).

  • Vector Crypto submitted for arch review (although the spec is not 100% finalized yet).
    • The proposal for "All Rounds" instructions should be pursued separately from the current proposed set of instructions (i.e. a separate ratification package) so as to not delay the current package of instructions from working their way down the path to ratification.  In parallel, further review and vetting by the community can proceed around these proposed "All Round" instructions and their intended use to create DPA-resistant AES instructions, as well as doing some form of associated PoC.

    • Reviewed handling of "improper" vl values and agreed with the current spec's mandate of non-integral vl/EGS causing an illegal instruction exception.
    • Reviewed handling of VLEN<EGW in relatively "narrow" vector implementations and agreed with the use of LMUL=2 when needed (which still allows for 16 vector register groups).

    • The proposed resolution within the TG to this week's vector rotate immediate issue looks good.

    • AR, as prelim feedback, is happy with the general direction of the proposed spec including the proposed instruction semantics, the opcode assignments, and the use of the (new) general vector concept of element groups.

    • AR also approves of the reuse or overlay of some vector crypto opcodes with the 'P' (aka Packed-SIMD) opcode space.  Since the P and V extensions have overlapping functionality, yet are largely suited to different application domains, they are considered mutually incompatible. This avails each extension of the other's major opcode without concern of collision.

    • The vector bitmanip extension looks fine.  In the future these may become part of a broader vector bitmanip extension, but this is a good set for now for crypto purposes.

    • As the spec is not quite completely finalized yet, completion of AR awaits a final ready-to-freeze spec.

  • IOMMU and whether Svnapot support should be mandatory or optional.  AR's view continues to be that the hardware cost of supporting NAPOT PTEs in at least the trivial form is tiny (~20 gates to decode NAPOT PTEs but otherwise treat them as normal 4K PTEs), whereas in general there is software cost (whether big or little) to supporting optionality (and little hassles like extension naming support for optional features).  In short, RV arch specs should support optionality where there is value to providing implementation flexibility (and the software support cost is reasonable), and conversely supporting optionality for negligible benefit is generally discouraged.  John will discuss further with Ved.

  • Review of latest Pointer Masking (Zjpm) spec
    • After a recent joint meeting with the J group chairs to review the latest pointer masking proposed spec and go over various questions and comments, an updated and improved spec will be created.  Completion of AR awaits submission of this updated spec.  CSR number assignments will be made based on the updated spec.

  • Zicntr/Zihpm will start public review.

41 - 60 of 1210