SBI RESET extension is optional. So S-mode software can always fallback on CONFIG_SYSREST to reset the system.

+ Paul/Palmer Any other comments/suggestions ? It would be great if we conclude either way and have some standard reset mechanism sooner than later.

I agree. Let's keep UEFI out of this discussion as UEFI support can't be mandatory on all platforms. Moreover, UEFI runtime services are implemented between same privilege levels. Thus, UEFI reset wou

I updated the subject to include the time (8AM PST). I also updated the calendar invite. So everybody's calendar should be updated with the google meet link instead of Zoom. FYI: The calendar in group

+Stephano Wednesday 8AM PST may not work as tech-chairs meetings are scheduled on that slot. I was recently made aware of that while setting up hypervisor syncup call. They are on a different calendar

For #2, I think device tree/ACPI would be a better choice. It's already well defined for ARM. Obviously, it needs to be adopted for RISC-V. https://elixir.bootlin.com/linux/v5.9-rc7/source/Documentati

That's awesome. I did not know that you have a working RTL implementation with H extension. Absolutely. I have added your talk to the agenda for upcoming meeting on 27th october. Yes. It would be very

For the entire series: Reviewed-by: Atish Patra <atish.patra@...>

I am not sure how to represent this without ambiguity. There will be two kinds of firmware interfaces. UEFI/ACPI that will use SBI internally for some of the runtime services (Not All). S-mdoe OS will

Current SBI interface provides these features that is outside scope of UEFI. 1. IPI, SFENCE, Hart State Management(CPU hotplug), Timer management In future, there will be RESET/SUSPEND (either direct

Looks good to me. I don't see a reviewed-by tag as this is not actual patch. I have approved the PR in github. https://github.com/riscv/riscv-sbi-doc/pull/61 For future reference, it is preferred that

The meeting is switched to Monday 9AM every week to avoid conflict. The calendar is updated as well. The next "Profiles and Platform Spec TS" meeting is scheduled on Mon, October 26, 9am – 10am. Sorry

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

There is a brief valid hart definition in binary encoding section as well. "any of the hartid from hart_mask is not valid i.e. either the hartid is not enabled by the platform or is not available to t

I am fine with either way.

Does it need to be specified in SBI specification or platform specification ? Platform specification anyways should have a section about state of machine while entering M/S mode. Keeping the same info

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

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

I think SBI specification should follow the same formatting as the platform spec. Here are few differences in generated pdf. 1. First page should contain the title and a version in next line with smal

I think the current version should be in the title page but in a next line similar to platform spec. I think we should move this to a change log section to be in compatible with Platform spec. Should