|
From: | Palmer Dabbelt |
Subject: | Re: [Qemu-devel] [PATCH for 4.1 v3] target/riscv: Expose time CSRs when allowed by [m|s]counteren |
Date: | Wed, 26 Jun 2019 01:25:26 -0700 (PDT) |
On Tue, 25 Jun 2019 23:58:34 PDT (-0700), address@hidden wrote:
On Wed, Jun 26, 2019 at 4:23 AM Jonathan Behrens <address@hidden> wrote:I just did some testing on a HiFive Unleashed board and can confirm what you are saying. The low 5 bits of both mcounteren and scounteren are writable (if you try to write 0xFFFFFFFF to them, they'll take on the value 0x1F) but even with the TM bit set in both mcounteren and scounteren the rdtime instruction always generates an illegal instruction exception.Then I would think the FU540 is not spec complaint :)
Ya, it's an errata. There's a handful of them :)
Reading through the relevant chapter of the spec, I still think that having mcounteren.TM be writable but making rdtime unconditionally trap is non-conformant. If other people feel strongly that rdtime should alwaysAgree. To test hardware (FU540) compatibility in QEMU, maybe we can add a cpu property to allow hard-wiring mcounteren.TM to zero?
In theory we should have properties to control the behavior of all WARL fields, but it's a lot of work. I'd be happy to take a patch for any of them.
require trapping into firmware then the natural change would be to simply hardwire mcounteren.TM to zero (the value in scounteren wouldn't matter in that case so it could be left writable). My own (biased) personal feeling is that this full implementation makes sense at least for the `virt` machine type because it represents a clear case where deviating from current hardware enables a performance boost, and would not break compatibility with any current software: both OpenSBI and BBL try to enable hardware handling of rdtime when the platform claims to support it.Regards, Bin
[Prev in Thread] | Current Thread | [Next in Thread] |