Open cmaiolino opened 8 months ago
To elaborate on the suggestion, there's currently no guidance for how to choose an ID for an experimental or custom SBI implementation, which means it's possible to get conflicts with future ID definitions. Reserving space for the future defined IDs, by creating an experimental ID space, helps ensure only experimental implementations are at risk of conflict.
I suggest we reserve 0 to 0x7fffffff for defined IDs and write guidance in the spec that SBI implementers use IDs from outside that space until they are ready to request a defined ID.
Regarding the testing, whether or not we check for a range of defined IDs or for an expected value is a bit independent. We can already always require an expected value to be input, so it doesn't matter if it's a defined ID or an experimental ID, but if we wanted to allow any defined ID to pass, then we need the range.
Hello, while writing a test for KVM unit tests, to test sbi_get_impl_id() function, I realized there is no way to check if the returned value is within an acceptable range. Discussing it with @jones-drew, he suggested to split the space in the listed implementation IDs and experimental IDs, analogous to Experimental SBI Extension IDs. Does anybody has any objection on updating the specification to split implementation IDs to include an experimental space? If no, I'd suggest reserving the upper 8 bits for experimental ids, but I'm new to riscv so I'm not sure if this is reasonable.