Re: [PATCH 1/1] target/riscv: fix VS interrupts forwarding to HS

2020-05-05 Thread Alistair Francis
On Fri, May 1, 2020 at 11:57 AM Jose Martins wrote: > > Reached out to Andrew Waterman. This was his response: > > "I think the encoding of the privileged modes is a red herring. HS is > inherently more privileged than VS, since it controls memory > protection and interrupt delegation for VS. > C

Re: [PATCH 1/1] target/riscv: fix VS interrupts forwarding to HS

2020-05-01 Thread Jose Martins
Reached out to Andrew Waterman. This was his response: "I think the encoding of the privileged modes is a red herring. HS is inherently more privileged than VS, since it controls memory protection and interrupt delegation for VS. Certainly the intent is that HS-mode interrupts are always enabled

Re: [PATCH 1/1] target/riscv: fix VS interrupts forwarding to HS

2020-04-30 Thread Jose Martins
> I'm not sure HS is a higher privilege mode. > > HS is privilege encoding 1, which is the same as VS (VU is obviously lower). I just checked the spec and it doesn't actually, explicitly state that HS is a higher-privilege mode than VS. I thought this was something implicit, but you might be right

Re: [PATCH 1/1] target/riscv: fix VS interrupts forwarding to HS

2020-04-30 Thread Alistair Francis
On Wed, Apr 29, 2020 at 2:08 PM Jose Martins wrote: > > > Your change just made it true for whenever virtulisation is enabled > > (in which case we don't need it). > > This is exactly my point. As I said in the commit message, the spec > clearly tells us that "Interrupts for higher-privilege modes

Re: [PATCH 1/1] target/riscv: fix VS interrupts forwarding to HS

2020-04-29 Thread Jose Martins
> Your change just made it true for whenever virtulisation is enabled > (in which case we don't need it). This is exactly my point. As I said in the commit message, the spec clearly tells us that "Interrupts for higher-privilege modes, y>x, are always globally enabled regardless of the setting of

Re: [PATCH 1/1] target/riscv: fix VS interrupts forwarding to HS

2020-04-29 Thread Alistair Francis
On Wed, Apr 29, 2020 at 9:07 AM Jose Martins wrote: > > > If the Hypervisor sets the V* interrupts why does it then want to > > receive the interrupt itself? > > I don't think this is a question of whether there is a use case for it > or not (I agree with you, of the top of my head I don't see wh

Re: [PATCH 1/1] target/riscv: fix VS interrupts forwarding to HS

2020-04-29 Thread Jose Martins
> If the Hypervisor sets the V* interrupts why does it then want to > receive the interrupt itself? I don't think this is a question of whether there is a use case for it or not (I agree with you, of the top of my head I don't see why would you forward v* interrupts to the hypervisor). However, f

Re: [PATCH 1/1] target/riscv: fix VS interrupts forwarding to HS

2020-04-27 Thread Alistair Francis
On Sat, Apr 18, 2020 at 11:01 AM Jose Martins wrote: > > When vs interrupts (2, 6, 10) are enabled, pending and not delegated > in hideleg, they are not always forwarded to hs mode after a return to > vs mode. This happens independently of the state of spie and sie on > the hs-level sstatus before

[PATCH 1/1] target/riscv: fix VS interrupts forwarding to HS

2020-04-18 Thread Jose Martins
When vs interrupts (2, 6, 10) are enabled, pending and not delegated in hideleg, they are not always forwarded to hs mode after a return to vs mode. This happens independently of the state of spie and sie on the hs-level sstatus before the return. Instead, the vs-level status sie state seems to be