Hi Furquan, Yes, let's do that. I will setup a meeting on Monday 27th 2022. We can continue the discussion later if we can not finish in an hour. Thanks! Sunil

Hello Sunil, Thanks for sending out these ECRs. After looking at these documents, we have a lot of comments/questions, but I think it might be productive to walk through the assumptions and approach

Hi All, Please review below Engineering Change Request (ECR) to update the ACPI spec for enabling basic ACPI support for RISC-V. 1) Add INTC structure in MADT Table -

Although the deadline has past, it was mentioned at the Software HC meeting last week that there are no candidates for the vice-chair position, so I would like to nominate myself. I have been

Do you mean SBI spec changes are merged in the spec but the SBI spec is not frozen by itself ? Release of the SBI specification - ratified version or frozen is fine ? As long as dependent specs can

More than this, the specification cannot go to Freeze (public review) until any SBI changes are in place. One thing we might want to consider is having an "SBI approval" process. That would allow SBI

It seems to me that the rationale and summary of the extension is insufficient, and non-normative commentary is lacking. The ensuing mailing list discussion suggests that there are additional

I agree With the current design there is no way for the supervisor software to reclaim the memory once it has shared it with OpenSBI. We can add a close() call, but it seems simpler and safer to

As I pointed out in an earlier message, the design using a shared memory block is a hindrance. Instead, each call should provide a pointer to the (virtual) address of the character buffer. Consider

A further use case requiring fast boot are automotive electronic control units, e.g., an infotainment unit. -- Konrad

<heinrich.schuchardt@...> wrote: Ahh I see. Sorry I misunderstood your comment. The designated shared memory for debug console is shared across the platforms while STA or PMU use case will

I have no security concerns. My thought was that it might be better to manage shared memory in a separate extension for all use cases. Best regards Heinrich

<heinrich.schuchardt@...> wrote: I would like to understand more about the security concerns you raised. Can you please elaborate on this ? As you pointed out, there are other possible use

Hi Stefano, <stefano.stabellini@...> wrote: We have legacy SBI v0.1 calls where most of them are replaced by newer SBI v0.2 (or higher) calls. Only the SBI v0.1 putchar() does not have a

The numbers you asked will help but I just wanted to add that in my opinion a per-character putchar interface is not suitable for production due to the reasons you mentioned. I would compile it out in

I think the extension was proposed to be a Debug console extension. In a production environment if 10's of VMs were booting having them emit to the physical console - where all of those outputs will

Even though we all (me included) tend to think that slowing down something like this will be inconsequential to the time to boot and/or who cares how fast or slow is boot time, in the past I have

Yeah, I think you are right that it is not a must-have feature but a nice-to-have feature.

Of course a console is needed. But I was questioning the need for something much more elaborate than a putchar/getchar interface. I understand its needed to port the hypervisor but I undersatnd it