FYI: here is a rough initial draft of the architectural options that I've been able to dig up.
I know that this is very, very likely to be incomplete.

This is written from the perspective of how to make our reference model model the behavior of a device under test.
That's a very different use case than what is needed for ACPI, so I have no clue which of these options require a
parameter to be supplied (as opposed to defining the parameter) and which are don't cares.

Most of this was derived from the Imperas simulator options.

Sail will eventually have CSR definitions that will be supplied from a YAML formatted riscv-config file that describes the properties of a CSR
(e.g. which are implemented, which bits are RW, what the RO values are, what the ranges of legal values are for RW fields, and what the illegal->legal mapping function is for WARL fields). Entries marked "use CSR definitions" means that don't need to be given names, but can be derived from that YAML description (though the profiles names are restrictions on top of the architecturally allowed behaviors for a particular profile)

The unified discovery spec will be encoding some of these as well, and perhaps some other things which could be derived from this.