As per my discussions with Philip, there will be a Firmware & Platform Services SIG which will cover all the platform services specs (SBI, UEFI, ACPI). It can spin off separate TGs for SBI/ACPI which

Since this is for debug and really early phase debug till enough of the guest boots up to use a VFIO based char driver provided by the VMM, I am not sure that the slowness matters. Even this SBI call

That aligns w/ my recollection on how we'll handle updates to SBI.

My understanding is that different TGs or SIGs will propose their own SBI extensions. Once a set of changes for next SBI spec release are finalized, the SBI TG can collect all new SBI extensions and

The legacy SBI v0.1 putchar() and getchar() are byte-level send/receive calls. This is very slow for virtualized world particularly KVM RISC-V because each SBI v0.1 putchar() or getchar() will trap

we have seen a number of SBI changes proposed (debug console, ap tee, ...). will there be one big rev ala priv 1.12, small fast tracks , something else? I also suggest that this either needs to be

Hello! Glad to see a new proposal to the SBI standard. Besides to discussion before, I may (if possible or proper) suggest an idea of not implementing this extension, for SBI should provide

<heinrich.schuchardt@...> wrote: The shared memory area in case of this SBI extension will be shared across all HARTs so the SBI implementation will ensure atomicity in setting/reading

Should we keep this simple in the SBI - only have register based inputs - to send and receive 1 byte in each call? Keeping it a simple out_byte or in_byte - a serial port like interface seems the

The memory type should be 0 (i.e. PMA) for the shared memory between SBI implementation and supervisor software. Before MMU setup, the memory type is by default 0 (i.e. PMA) so we don't have to

Clearly, if we have a separate SBI extension to manage shared memory then we will end-up with such memory management calls. Memory allocators are generally hard to get it right and this also adds lot

Hi Anup, Here are my thoughts: * Guest memory access: I think this would be the first SBI extension to require access to guest memory. This needs to be considered carefully, but I think the higher

Am Donnerstag, 2. Juni 2022, 10:50:56 CEST schrieb Heiko Stübner: though, how does that relate to the time before MMU setup? I.e. in response to Heinrich's mail you talk about svpbmt, so I guess

Currently this function is just a nop(). It is not needed in this revision of the extension. The function might be called repeatedly by different threads with different values. How do you want to

Am Donnerstag, 2. Juni 2022, 10:47:58 CEST schrieb Anup Patel: ok, sounds like a plan as well :-)

Heinrich has a similar suggestion so please see my response to his comment. Regards, Anup

You can easily create multiple pre-populated strings using ".asciiz" in assembly sources. Just set the base address of pre-populated strings once on boot hart and print from anywhere using usual 4-5

<heinrich.schuchardt@...> wrote: Usually, the serial port related code in M-mode firmware only uses status and data registers so for most serial ports support the M-mode firmware will adapt

There are variety of ways in which supervisor software can use tarea_offset: 1) Use lock to serialize access to shared memory and always use fixed offset (maybe zero) from all HARTs 2) No lock to

Hi Anup, Am Mittwoch, 1. Juni 2022, 18:17:32 CEST schrieb Anup Patel: typo in the "div_by_2" (not 4 like below and in the function itself) ? This will vastly reduce the number of needed ecalls when