Reviewed-by: Atish Patra <atish.patra@...> -- Regards, Atish

The following files have been uploaded to the Files area of the tech-unixplatformspec@... group. /hypervisor_update/riscv_rocket_hypervisor_spinto.pdf By: Atish

Hi Allen, The “riscv64gc” is the default ISA for which Linux, hypervisors, and distros are compiled. Most of the optional features which you mentioned are detected at boot-time/run-time

Hi all, Here is the deck from the hypervisor sync-up call. Thanks Sandro

I think you are right that it should be totally possible to write an OS/software stack without any of the optional features (though someone would have to sanity check that). What would be way harder

To say "riscv64gc is standard; pester the OS if you want to know what other extensions are supported" implies that shrink-wrap software To standardize the hardware/firmware-to-OS interfaces, is it

In practice I'm not sure how much of a distinction there really is. Any given application binary is pretty much only going to work on one OS, so either the OS works across all implementations and you

let's recall that there are two end results we'd like to see: - being able to run the same u mode application binary from implementation to implementation and get the same results. - being able to run

... I would suggest something here like this, because I see three different modes of use, and they are mentioned further down but in passing, but not as explicitly as this. I know that personally my

Is this cache line references, or loads/instruction fetches which access the cache? E.g. if two instructions come from the same cache line, does this counter increase by two or one? And why are these

In configuration-structure we have struggled with this problem a little as well. So far we're using YAML/JSON5. It doesn't matter to me which of these (or equivalent) formats is used, but a

Any reason why HARDWARE is all-caps? Also: we should pick one format for CSRs and stick with it. The following formats are already present in the spec: I'm personally fond of `csrname.csrfield`,

This patch adds SBI performance monitoring unit (PMU) extension which allows S-mode (or VS-mode) software to configure HARDWARE/SOFTWARE performance counters with help of M-mode (or HS-mode)

one of the reasons profiles and configs are part of the profiles and platform group is because there were too many formats. some have inherited formats but many are ours that are homegrown. I suggest

Named fields help those of us with bad memories. How about using yaml? profile: user: linux firmware: uefi supervisor: opensbi hardware: rackmount processor: rv64gc boot: uefi

I'm a little concerned that the Processor interface is a bit too concise. Saying that something supports RV64GC may not provide enough information, because the number of HW options available to an

Hi Al,

Hi All, We will continue to use WebEx for Hypervisor sync-up until a Zoom call is hosted by RISC-V International for Hypervisor Sync-up. Here's the agenda for tomorrow's hypervisor sync-up call: 1.

Could this sentence be reduced to just "A platform is the sum total..."? I'd argue that a specification is only useful insofar as the constraints it imposes are useful. However, if one does not wish