sail-riscv
sail-riscv copied to clipboard
riscv
Svadu Support
I'm going to implementing the support for the Svadu. RISC-V Sail already has the [-d|--enable-dirty-update] flags. I wanted to get an opinion on if we should remove those flags and only handle such behavior in the presence of Svadu extension. This was what was done in Spike
That will then remove the ability to match what some real legal implementations do that RVI decided to retroactively make illegal.
For example, QEMU has done dirty updating for many years conforming to prior versions of the privileged spec, well before the conception of Svadu, and we do fuzz our CHERI-extended QEMU against our CHERI-extended Sail model, including with virtual memory tests, so it is important to us that this legitimate functionality not be removed just because RVI decided to remove a feature from RISC-V. I also know that some of Bluespec's cores have implemented dirty updating for several years if you use certain configurations.
Hm, or maybe Svadu is just giving a way to control it, and without Svadu you can get the old behaviour? Either way the old behaviour needs to stay, it's a feature that has been and legitimately can continue to be implemented.
What would you recommend w.r.t. direction on this front? If we want to keep the enable-dirty-update flag I can interrogate both plat_enable_dirty_update() and CSR field with the right precedence.
Make -d + --enable-svadu an illegal combination, otherwise honour the behaviour of whichever is set?
(The only alternative would be to have -d + --enable-svadu default menvcfg.HADE or whatever it is to 1, but that seems like a bad idea)
Ok. Sounds like you are proposing an --enable-svadu flag. I hadn't sorted out how extension processing was done yet. I'll proceed down this path and see what I can sort out. Thanks.
I think there are ambitions to overhaul extension enabling, but that is what's been done so far when it's needed to be configurable (as opposed to just new instructions that can be unconditionally enabled because you don't notice their existence until you try to use them).
The support for Svadu is just an indication that there is HW support for HW A/D update. It;s absence says nothing. This extension is not really an extension; it's a restriction on the legal value of an existing unnamed architectural option. I don't like calling it an extension - since it already existed before this was (or will be) ratified, but was overruled.
On Wed, Feb 15, 2023 at 2:19 PM Jessica Clarke @.***> wrote:
I think there are ambitions to overhaul extension enabling, but that is what's been done so far when it's needed to be configurable (as opposed to just new instructions that can be unconditionally enabled because you don't notice their existence until you try to use them).
— Reply to this email directly, view it on GitHub https://github.com/riscv/sail-riscv/issues/221#issuecomment-1432123549, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHPXVJROTAULCDZ636HOGIDWXVI73ANCNFSM6AAAAAAU5MKQN4 . You are receiving this because you are subscribed to this thread.Message ID: @.***>
Jessica wrote: "There are ambitions to overhaul the extension enabling..."
Yes there are, driven mostly by me. (I intend to make use of the RISCV-Config YAML structures to configure the Sail model, but that won't happen in your timeframe, Aaron. BTW, I am nearing completion of a cookbook example describing how to add extensions and CSRs to the model.)
For near term, just add a command line switch just as you mentioned (I also have some documentation on that as well). In the future, I'll retrofit your solution. Which brings me to the next comment ...
You should contact the maintainers of the RISCV-Config structures and figure out how you will specify this in the YAML files. The maintainers are: Neel Gala and Pawan Kumar (cc'd on this email).
Bill Mc.
On Wed, Feb 15, 2023 at 7:59 PM Allen Baum @.***> wrote:
The support for Svadu is just an indication that there is HW support for HW A/D update. It;s absence says nothing. This extension is not really an extension; it's a restriction on the legal value of an existing unnamed architectural option. I don't like calling it an extension - since it already existed before this was (or will be) ratified, but was overruled.
On Wed, Feb 15, 2023 at 2:19 PM Jessica Clarke @.***> wrote:
I think there are ambitions to overhaul extension enabling, but that is what's been done so far when it's needed to be configurable (as opposed to just new instructions that can be unconditionally enabled because you don't notice their existence until you try to use them).
— Reply to this email directly, view it on GitHub <https://github.com/riscv/sail-riscv/issues/221#issuecomment-1432123549 , or unsubscribe < https://github.com/notifications/unsubscribe-auth/AHPXVJROTAULCDZ636HOGIDWXVI73ANCNFSM6AAAAAAU5MKQN4
. You are receiving this because you are subscribed to this thread.Message ID: @.***>
— Reply to this email directly, view it on GitHub https://github.com/riscv/sail-riscv/issues/221#issuecomment-1432360893, or unsubscribe https://github.com/notifications/unsubscribe-auth/AXROLOAFMH4NEPB3GOX25KLWXWCX7ANCNFSM6AAAAAAU5MKQN4 . You are receiving this because you are subscribed to this thread.Message ID: @.***>
-- Bill McSpadden Formal Verification Engineer RISC-V International mobile: 503-807-9309
