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

[snip...] Per the discussion this morning, the wiki has been updated with my notes from today's meeting [0]. Please edit or comment if I missed something or got something wrong, or if you just have

I think there is a lot of confusion here because the discussion does not separates the semantic and the syntax/implementation of the specifications. Reusing the *semantic* defined elsewhere by

What do people think about Google Meet? (We use that internally and with external parties.) Greg

It's the mechanism we have at the moment. Yes, understood. For good or ill, this is what the foundation makes available up front so it was the tool at hand. What would be preferred? I have no

For me, the biggest factor is that the "Rich OS" platform should have only a single RESET interface for S-mode. I personally don't really care whether that means via SBI, an MMIO device, or any other

The RISC-V is a very different architecture compared to ARM/ARM64 architecture so we should not be blindly adopting specifications from ARM world without fully studying the technical complexity.

The core issue here isn't a technical one, I think. All of the technical issues seem either trivial to solve or seem unimportant for this use case (although Anup clearly has a different

You have to be willing to join Zoom calls to then discuss if Zoom calls are ok? Numerous companies have banned employees using Zoom. Not to mention the dishonest claims they have made and the poor

From: tech-unixplatformspec@... <tech-unixplatformspec@...>On Behalf Of Paul Walmsley Sent: 10 September 2020 20:30 To: tech-unixplatformspec@... Subject: [RISC-V] [tech-unixplatformspec] Proposal:

My opinion on this hasn't changed for the past year or two: we should avoid reinventing the wheel: https://lists.riscv.org/g/tech-unixplatformspec/message/226

The nice thing about standards is that you have so many to choose from. - attributed to Andy Tanenbaum Western Digital engineers have proposed that the RISC-V

please make sure governance includes the topics found in slide 2 of the org chart slides

Hi Greg, Option 1 looks better considering two-stage address translation. If top 2-3 bits in the PA are used for other purposes, the GPA also needs to behave in the same way, which means reduced

Here's the proposed agenda for the upcoming meeting of the Platform Spec Working Group. If there's something you'd like to add, just let me know now or during the meeting. Please note, too, that I'm

Greg, I would also be inclined towards option 1, based purely on orthogonality: without some extra considerations, the same page could be inadvertently (as in "all too easily by mistake") be used with

Regarding your virtualization question: Yes, this has been considered. Either option would have attribute overrides coming from both stages of address translation page tables - that would be combined

(I’m new to this email alias so I may be missing the context of past discussions. I apologize up front if I’m rehashing past discussions.) My preference would be Option #1 since I’m familiar

I thought the major issue with #1 was how to keep PTE based attributes isynchronized with M-code on the same hart running in bare mode that has no PTE bits to look at and might access without

Hi Greg, I am inclined towards Option#1 provided the new PTE format is compatible with existing PTE format for Sv32/Sv39/Sv48. Is the Option#1 documented somewhere ? Regards, Anup