1. tech-privileged@lists.riscv.org
  2. Messages
   Date   
Re: Meaning of Implemented in Sstc specification

Oscar Jupp
 

Dear Greg,
Thank you for your reply.
I am sorry that I miss the vital information.

Regards,
Oscar Jupp

---- Replied Message ----
From Greg Favor<gfavor@...>
Date 11/21/2022 12:44
To jupposcar<jupposcar@...>
Cc tech-privileged@...<tech-privileged@...> ,
 kenney@...<kenney@...>
Subject Re: [RISC-V] [tech-privileged] Meaning of Implemented in Sstc specification
On Sun, Nov 20, 2022 at 4:11 AM jupposcar <jupposcar@...> wrote:
Dear architect,
SSTC spec said: "When STCE in menvcfg is one but STCE in henvcfg is zero, an attempt to access stimecmp (really vstimecmp) when V = 1 raises a virtual instruction exception, and VSTIP in hip reverts to its defined behavior as if this extension is not implemented.”
But when STCE in menvcfg is zero and STCE in henvcfg is one, What is the behavior of VSTIP in hip?

The Sstc spec, in the Env Config Support section, says (with my underline):

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.


Greg
Re: Meaning of Implemented in Sstc specification

Greg Favor
 

On Sun, Nov 20, 2022 at 4:11 AM jupposcar <jupposcar@...> wrote:
Dear architect,
SSTC spec said: "When STCE in menvcfg is one but STCE in henvcfg is zero, an attempt to access stimecmp (really vstimecmp) when V = 1 raises a virtual instruction exception, and VSTIP in hip reverts to its defined behavior as if this extension is not implemented.”
But when STCE in menvcfg is zero and STCE in henvcfg is one, What is the behavior of VSTIP in hip?

The Sstc spec, in the Env Config Support section, says (with my underline):

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.


Greg
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
101 - 120 of 1272