``mtime`` returns random values while reading from U-mode

[francois141]

When attempting to read the mtime register in userspace, it appears to return random values. Below is an example of the output that demonstrates this issue.

[Warn  | miralis::virt] > Reading from mtime 9673451624126742528
[Warn  | miralis::virt] > Reading from mtime 24489422485454848
[Warn  | miralis::virt] > Reading from mtime 8890951188871118848
[Warn  | miralis::virt] > Reading from mtime 2193254118041059328
[Warn  | miralis::virt] > Reading from mtime 6088586320739827712
[Warn  | miralis::virt] > Reading from mtime 13153608236177293312

To reproduce the issue, execute the following commands:

git checkout mtime-issue; cargo run --package runner -- run --config {{qemu_virt}} --firmware interrupt

[CharlyCst]

Interesting, it seems to be working on my machine:

[Warn  | miralis::virt] > mtime: 43660
[Warn  | miralis::virt] > mtime: 47030
[Warn  | miralis::virt] > mtime: 48020
[Warn  | miralis::virt] > mtime: 48990
[Warn  | miralis::virt] > mtime: 50020
[Warn  | miralis::virt] > mtime: 50990

Which version of QEMU are you using (qemu-system-riscv64 --version)? I am on 9.0.1.

[francois141]

I use an older version

fran-ois-costa@fran-ois-costa-1-01:~$ qemu-system-riscv64 --version
QEMU emulator version 8.0.4 (Debian 1:8.0.4+dfsg-1ubuntu3.23.10.5)
Copyright (c) 2003-2022 Fabrice Bellard and the QEMU Project developers

[CharlyCst]

I see, it should not be older than the CI though so I am a bit surprised.

The mtime register is a memory-mapped register on the CLINT (Core Local INTerruptor). With Miralis we virtualize the CLINT so the firmware traps when reading it and Miralis emulates the read.

You can check if Miralis reads sensible values by setting trace = ["miralis::driver"] in your config, see: https://github.com/CharlyCst/miralis/blob/332ed085096d624f59beb2fb3afa105b579b043b/src/driver.rs#L41-L49

If Miralis reads sensible values then we have a problem when returning it to the firmware, if it doesn't then maybe the platform has a different configuration somehow (like the CLINT being at another address).

[francois141]

@CharlyCst It seems that it doesn't read the CLINT at all. I will investigate that. If there is an issue, I will fix it.

Update: It works on my second computer. This is interesting....

[CharlyCst]

Wow, ok this is getting stranger ^^ do you two computers have the same qemu version?

[francois141]

The other computer has : QEMU emulator version 9.0.2. I upgraded my qemu version and it seems to work. Better build qemu from scratch as the classic sudo apt-get install.....

Let me add this in the readme :-)

[CharlyCst]

Could this be related to the bug in #161?

I am not super enthusiastic about requiring a minimal QEMU version, it will make onboarding harder and unless we can get reasonably confident that the bug is in QEMU (could be, who knows) I would rather suspect that we are doing something wrong somewhere... Better fix the bug than hide it :)

[CharlyCst]

Doesn't seem to be related to the issue in #161 after all. I'll investigate on an old machine next week when I'll be back at the lab.

[CharlyCst]

Update: it works on another of my machines with QEMU version 6.2.0. So the QEMU version doesn't seem to be the problem...

I will keep the issue open, we can discuss that in person and decide if we need more investigation, but I will close https://github.com/CharlyCst/miralis/pull/176 as it doesn't look like the QEMU version is at fault.

[francois141]

As you wish. For me updating the qemu version solved the problem. This is strange :)