Hypervisor support with no Page Tables

[Javed Osmany]

Hello

In Privilege spec version 20211203, on page 99, for the HyperVisor extension, it says:

".. and standard page-based address translation must be supported, .."

Then on page 123 of the above version of the Privilege spec, it says WRT Two-Stage Address Translation: " ..Although there is no option to disable two-stage address translation when V=1, either stage of translation can be efficievely disabled by zeroing the corresponding vsatp and hgatp register".

I would like to support Hypervisor support by implementing H-extension, but don't want to do any virtual to physical translation (real-time automotive application). Thus vsatp.MODE = 0x0 and hgatp.MODE = 0x0 in my example.

QS1: Is it possible to support the runing of type-1 Hypervisor on a H-extension RISC core, without having page-based address translation?

The intention would be to make use of the PMP feature to provide the memory address checking (all addresses would then be physical) and  the corresponding memory access protection checks?

Thanks in advance

JO

[Tommy Murphy]

Third separate thread on basically the same issue.

Is that really necessary?

* https://groups.google.com/a/groups.riscv.org/g/hw-dev/c/JwEtId28Imo

* https://groups.google.com/a/groups.riscv.org/g/hw-dev/c/sf8zywHNOkE 

[Javed Osmany]

Sorry, but have not received any reponse when posting to the HW group. Thought, maybe i was posting the query to the wrong group.

JO

[Andrew Waterman]

On Mon, Sep 4, 2023 at 6:39 AM Javed Osmany <livi...@gmail.com> wrote:

Hello

In Privilege spec version 20211203, on page 99, for the HyperVisor extension, it says:

".. and standard page-based address translation must be supported, .."

Then on page 123 of the above version of the Privilege spec, it says WRT Two-Stage Address Translation: " ..Although there is no option to disable two-stage address translation when V=1, either stage of translation can be efficievely disabled by zeroing the corresponding vsatp and hgatp register".

I would like to support Hypervisor support by implementing H-extension, but don't want to do any virtual to physical translation (real-time automotive application). Thus vsatp.MODE = 0x0 and hgatp.MODE = 0x0 in my example.

If the implementation doesn't support address translation, then it wouldn't conform to the standard; it would be a custom extension that happens to look very similar to the hypervisor extension.  You could do this if you wanted, but you couldn't accurately describe the implementation as supporting the RISC-V hypervisor extension.

QS1: Is it possible to support the runing of type-1 Hypervisor on a H-extension RISC core, without having page-based address translation?

The intention would be to make use of the PMP feature to provide the memory address checking (all addresses would then be physical) and  the corresponding memory access protection checks?

The hypervisor doesn't have access to the PMP registers; they're only accessible from M-mode.  You'd probably find the need to define new memory-protection features as part of your custom extension.

 

Thanks in advance

JO

--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/0cbf7a05-d910-4ecf-b540-e2035d8152d0n%40groups.riscv.org.

[Jeff Scott]

☹

 

This is a common use case.  Any chance of a standard extension to support this?

 

Jeff

 

From: Andrew Waterman <wate...@eecs.berkeley.edu>
Sent: Tuesday, September 5, 2023 3:54 PM
To: Javed Osmany <livi...@gmail.com>
Cc: RISC-V ISA Dev <isa...@groups.riscv.org>; J Osmany <liv...@hotmail.co.uk>
Subject: [EXT] Re: [isa-dev] Hypervisor support with no Page Tables

 

Caution: This is an external email. Please take care when clicking links or opening attachments. When in doubt, report the message using the 'Report this email' button

 

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CA%2B%2B6G0BzTv45F%2B%3DAHNAHMzFntcvD6s9shQjDkPEiJw5VoTVjLA%40mail.gmail.com.

[Andrew Waterman]

I wouldn't be surprised if that happens eventually.  The hypervisor extension was defined this way for expediency, not for ideology.  Without some form of memory protection, the hypervisor extension isn't terribly useful.  But the authors of the hypervisor extension weren't interested in taking on the additional effort of defining an alternate memory protection scheme, leaving paging as the only option.

[Ved Shanbhogue]

Jeff Scott wrote:
>This is a common use case. Any chance of a standard extension to support this?

You may want to look at this proposed extension: https://github.com/riscv/riscv-spmp

regards
ved

[Javed Osmany]

Hello

Thank you for your answer.

>> If the implementation doesn't support address translation, then it wouldn't conform to the standard; it would be a custom extension that happens to look very similar to the hypervisor extension.  You could do this if you wanted, but you couldn't accurately describe the implementation as supporting the RISC-V hypervisor extension.

Therefore, based on what you say and what is in the privilege spec,  the implementation needs to support at least on level of page based address translation (either VS stage or G stage translation).

>> The hypervisor doesn't have access to the PMP registers; they're only accessible from M-mode.  You'd probably find the need to define new memory-protection features as part of your custom extension.

So my initial thinking was to define two PMP schemes.

1) PMP_HS - Make use off the M-mode pmpaddrx and pmpcfgx registers. When virtualisation was not on, core would be in either [M, HS, U] mode. So if core was in [HS, U] mode, it would need to transition to M-mode to be able to access these pmp registers. Therefore these PMP_HS registers would then provide the memory access and protection checks.

So an application running in user mode, making a memory access, how does the core switch from U to M mode, to do the PMP lookup and then switch back to U mode to determine if the memory access check passed or failed? 

2) PMP_VSU - Define a similar set of pmpaddrx and pmpcfgx registers in the Hypervisor and VS CSR address space. So when virtualisation is enabled, core is in VS or VU mode. These new PMP CSR registers would be accessible from VS mode. So an application running as a VM in VU mode would then have to switch to VS mode to be able to access these new PMP registers and determine if the memory access check passed or failed and then switch back to VU mode.

So i guess even if this dual PMP scheme was viable, it would still not be compliant to the H-extension, since no page based address translation is implemented.

I got the pointer to the SPMP working proposal. Will study this in detail.

Best regards

JO

[Javed Osmany]

So just think about this a little more ....

>> So an application running in user mode, making a memory access, how does the core switch from U to M mode, to do the PMP lookup and then switch back to U mode to determine if the memory access check passed or failed? 

SW access to the pmpaddrx and pmpcfgx registers can only be done in M-mode. Once these registers have been programmed, then thier values are available to the HW to access and do the memory translation and protection checks.

So in the [HS_PMP, VSU] scheme i was exploring to do the memory translation and protection check, if the core was in HS mode, it would thne switch to M mode via an ecall instruction, access and update the pmpadddrx and pmpcfgx registers and then switch back to HS mode via an eret instruction.

Best regards

JO

[Jeff Scott]

Thanks! So we have PMP, Smepmp, and SPMP. Does a table exists comparing these?

Jeff

-----Original Message-----
From: Ved Shanbhogue <v...@rivosinc.com>
Sent: Tuesday, September 5, 2023 6:21 PM
To: Jeff Scott <jeff....@nxp.com>
Cc: Andrew Waterman <wate...@eecs.berkeley.edu>; Javed Osmany <livi...@gmail.com>; RISC-V ISA Dev <isa...@groups.riscv.org>; J Osmany <liv...@hotmail.co.uk>
Subject: Re: [EXT] Re: [isa-dev] Hypervisor support with no Page Tables

Caution: This is an external email. Please take care when clicking links or opening attachments. When in doubt, report the message using the 'Report this email' button

[Javed Osmany]

Hello

Is it possible for me to be part of the working group, to provide input from our company (IMG) prespective?

Tks in advance

JO

[Tommy Murphy]

> Is it possible for me to be part of the working group, to provide input from our company (IMG) prespective?

https://riscv.org/using-the-working-groups-portal/ 

[J O]

Tks for the pointer. 

JO

Sent from Outlook for iOS

---

From: Tommy Murphy <tommy_...@hotmail.com>
Sent: Thursday, September 7, 2023 11:44:33 AM
To: Javed Osmany <livi...@gmail.com>; RISC-V ISA Dev <isa...@groups.riscv.org>
Cc: Ved Shanbhogue <v...@rivosinc.com>; Andrew Waterman <wate...@eecs.berkeley.edu>; Javed Osmany <livi...@gmail.com>; RISC-V ISA Dev <isa...@groups.riscv.org>; J Osmany <liv...@hotmail.co.uk>; Jeff Scott <jeff....@nxp.com>
Subject: Re: [EXT] Re: [isa-dev] Hypervisor support with no Page Tables

 

[Jeff Scheel]

Is it possible for me to be part of the working group, to provide input from our company (IMG) prespective?

Javed, only RISC-V members can join working groups and contribute.  This is to ensure intellectual property issues are understood and addressed.  

Thus, if you want to contribute, you will need to join RISC-V as an (free) individual member or have your employer join by signing up.

Membership information, including the online form, is found here: https://riscv.org/membership/

We look forward to having you join us!

-Jeff

--

Jeff Scheel (he/him/his)

Director of Technical Programs, RISC-V Foundation

--

You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/c846f00a-b7e1-4137-9191-e696efe9cec1n%40groups.riscv.org.

[Javed Osmany]

Thanks Jeff for the pointer.

Best regards

JO