I would also expect to have the OS make the UD message (in its raw, unparsed form) available to userspace consumers. In other words: even if the OS works off DT/ACPI tables, the full information

As per my understanding, early boot refers to OS world. Introducing UD to the S-mode is not an option in my opinion. We already have all the infrastructure for DT/ACPI in rich OS land. As Phillip

I think of UD being orthogonal to this discussion. Firmware world | OS world | [UD, etc. ]---firmware builds-+->[ACPI/DT]--->OS

agreed. but it all starts with UD. we had every extension devising their own discovery mechanism and everyone agreed that was not the correct thing to do. We reduced UD this year to just ASN and

Unified DIscovery is expected to be used by firmware to populate DT and ACPI/UEFI tables. Philipp.

just a reminder that we should be moving to unified discovery during boot to feed everything. not isa strings. not csrs. -------- sent from a mobile device. please forgive any typos.

Hi, I'm top posting with some notes that Furquan helped me put together to cover the things we've been talking about. We may want to put these and future notes somewhere else (drive, github, etc) so

Hi All, First off, please redirect me where the most appropriate forum is to discuss this topic. I am casting a fairly wide net, but that's just trying to cover those who are impacted. We can convene

Hi All, Thanks a lot for great feedback over last week on the ECRs. I have created version 2 of the ECRs addressing most of the comments. We will be discussing this version of the ECRs in this week's

Sunil Hi - July 4 is a holiday in the US. COuld we meet on 5th? regards ved

You have been invited to the following event. Ad-hoc ACPI ECR Review meeting - Part 2 When Mon Jul 4, 2022 9:30pm – 10:30pm India Standard Time - Kolkata Joining info Join with Google

In case the meeting details are not reflecting in the invite, here is the info: Meeting link: https://zoom.us/j/7237830759 Passcode: 741796 Join link:

I get the intent now. But we may not want to prohibit that. We may want to document that the SBI will access this memory using the PMA attribute. If the supervisor has accessed this same location

The term "domain" is not used in the proposal since it is OpenSBI specific. My comment was mainly for Heinrich since he is already aware of OpenSBI domains. In general, other M-mode firmwares might

So domain is a new term which is not presently defined in the privileged specification or in the SBI specification. I think I get what you may be stating here i.e., M-mode may configure/ reconfigure

As this is a security feature we should require: The SBI MUST check that the full memory range is read-accessible by the caller. Here too we should make it clear if the SBI MUST or MAY check the

The term "supervisor-mode" over here means: * HS-mode or VS-mode on systems with H-extension * S-mode on systems without H-extension (Please see the introduction chapter of SBI specification) In

Why should only S-mode and not HS-mode be allowed? I think the modes that are allowed to access this extension should be enumerated more clearly. How are systems treated that only have M-mode and

Hi All, Based on feedback, below is the updated draft proposal of the SBI Debug Console Extension ... The motivations behind this proposal is as follows: 1) There is no new SBI extension replacing

Sounds good. Thanks, Sunil! - Furquan