`riscv`: H-Mode and VS-Modes?

[vm-kit]

Is it in scope to include the hypervisor extension register read/writes to this crate?

[romancardenas]

I would say that the hypervisor extension is out of the scope for the rust-embedded WG, as it is not typical in embedded devices. However, if you find a use case that motivates supporting this extension, then we can explore it.

[vm-kit]

I would say that the hypervisor extension is out of the scope for the rust-embedded WG, as it is not typical in embedded devices. However, if you find a use case that motivates supporting this extension, then we can explore it.

@romancardenas hello. thank you for responding. I understand H/VS modes probably aren't normally in an embedded environment. I am going to try to build a hypervisor in rust/riscv, and so this repo looks amazing for m level and some others. There is a nice macro system implemented for making it easy to read and write csr's like mstatus. Rather than having to reimplement that within my own project, I could reuse that here. I would love to use the wealth of knowledge you all have for my own selfish review of correctness.

I would be happy to do the work myself and submit a PR here, as I try to learn and understand the risc-v specs for H/VS modes.

[vm-kit]

When is enum macro used vs the single field by itself?

#[cfg(not(target_arch = "riscv32"))]
read_write_csr_field! {
    Hstatus,
    vsxl: [32:33],
}

csr_field_enum! {
    SPV {
        default: WasVModeOff,
        WasVModeOff = 0,
        WasVModeOn = 1,
    }
}

...
read_write_csr_field! {
    Hstatus,
    /// Supervisor Previous Virtualization mode
    spv,
    SPV: 7
}

But i had seen a single bit flag used for enums i believe in another register implementation

[romancardenas]

The prior returns a raw number that corresponds to bits 32 to 33. In the latter, you work with bit 7. But instead of returning true/false, you return an SPV enum variant that encodes this information. Usually, enums are preferred, as they are more natural for the reader (the name hits its meaning)

[vm-kit]

Alright, I've done a little bit here. I'm getting an error when using the changes I made in this crate.

_start is loaded right at 80200000, and the open sbi output in qemu shows. and the manual asm hstatus spv bit below set seems to work as code continues to the next logging statement

#[unsafe(link_section = ".text._start")]
#[unsafe(no_mangle)]
pub extern "C" fn _start() -> ! {
    unsafe {
        let mut hstatus: usize;
        core::arch::asm!(
            "csrr {0}, hstatus",
            out(reg) hstatus
        );
        hstatus |= 1 << 7;
        core::arch::asm!(
            "csrw hstatus, {0}",
            in(reg) hstatus
        );
        // Traps!
        //Misa::set_h(true);
        //let mut h = riscv::register::hstatus::read();
        //h.set_spv(SPV::VSModeOn);

        // HELLO WORLD LOG HERE!!!!

Both the commented out Misa::set_h and either the set_spv or hstatus::read traps. I'm not sure what type of trap. it is resetting.

Code is here:
https://github.com/vm-kit/riscv/blob/hstatus/riscv/src/register/hstatus.rs
https://github.com/vm-kit/riscv/blob/hstatus/riscv/src/register/misa.rs

I don't think the misa call is required since h should already be enabled. I have tried just doing hstatus::read() and h.set_spv, and it traps too. Here is my qemu args

	qemu-system-riscv64 -cpu rv64,h=true,sstc=true -m 256 -bios default -semihosting -machine virt -nographic -kernel test

Any assistance would be much appreciated.

edit
the hstatus::read() resets by itself!

edit2
If there is anything else you notice I'm not following for standards let me know

edit3
Every register is causing some sort of issue. trying to read mstatus causes reset.

edit4
I've tried using the published crate and has the same issue. I'm missing something.

I even tried just getting the mhartid to see if ineeded to only run on the first one, but getting mhartid also traps/resets

[vm-kit]

I can't figure this out. I thought it was needing to be riscv64imac but that was just because I hadn't updated my make file to point to the new target

[romancardenas]

The _start symbol is provided directly by riscv-rt: https://github.com/rust-embedded/riscv/blob/cdae64a64a5a22d5e8fb0a2ffaa98dc60ccb80cd/riscv-rt/src/asm.rs#L41C1-L41C7

Also, memory might not be available at that point, so using Rust directly is undefined behavior.

I'm not sure how you should proceed, but probably you need to do stuff in assembly