Heinrich Schuchardt <xypron.glpk@...> 於 2021年6月28日 週一 下午4:32寫道： That's true. On the server platform, RTC doesn't work alone. It incorporates with BMC to get the time information

The way that UEFI reports local time zones is unsatisfactory: There is an offset to UTC and a daylight savings flag but this does not allow to derive on which day daylight saving switches (you could

Hi Abner, "," is required before your name here.

Jonathan Behrens <behrensj@...> 於 2021年6月25日 週五 下午11:11寫道： That depends on how do you implement GetTime/SetTime functions for the platform. You can always not returning

From: Abner Chang <abner.chang@...> Signed-off-by: Abner Chang <renba.chang@...> Signed-off-by: Abner Chang <abner.chang@...> --- contributors.adoc | 1 + 1 file changed, 1

From: Abner Chang <abner.chang@...> Initial version of Interrupt Controller, Software Interrupt, and Timer Requirements. This patch combines the text sent out by Kumar and the patch Abner sent

OK agreed. We can remove the ASID requirement all together. Regards Kumar

Recent platform discussion about this question concluded the same. Greg

Significant HW cost in TLBs. My take is we should avoid imposing this requirement altogether. Kernel software needs to support the no-ASID case, anyway, so we aren’t simplifying software by imposing

Requiring ASID support without specifying the number of bits means that even 1-bit ASIDs would be allowed, even though they'd be essentially useless. That said, I don't have a strong feeling about a

Hi Jonathan, Regarding ASID and VMID support, we are mandating those only for the Server Extension within the OS-A platform and not for OS-A platform base. We could consider a minimum of 12-bits for

Hi All, The next platform HSC meeting is scheduled on Mon Jun 28th at 8AM PST. Here are the details: Agenda and minutes kept on the github

Is this supposed to include more detail than just "ASID support" and "VMID support"? Not sure if those are just placeholder section headings for now, but I'd expect to at least see a requirement of

ARM went through this issue with the variety of CPU designs that people have done (both outside and inside ARM). In particular, as people went to larger and/or more power-efficient L1 caches, they

Any chance that we can ban EFI_UNSPECIFIED_TIMEZONE and/or require that time is always UTC? Jonathan

From: Abner Chang <abner.chang@...> Signed-off-by: Abner Chang <renba.chang@...> Signed-off-by: Abner Chang <abner.chang@...> --- contributors.adoc | 1 + 1 file changed, 1

From: Abner Chang <abner.chang@...> RTC (Real-time Clock) Real-time clock is the server basic system peripheral to provide the real date/time information for server to manage the system date,

The intent seems to be that caches shall appear (to software) to be non-aliasing. Depends on the internal organisation of a VIPT cache (and its size/number of index bits)... The requirement clearly

I agree with Andrew. What does it mean for caches to appear to software in any particular way? Unless you're talking about something like CMOs, aren't caches entirely transparent to software? In

Hi Andrew, Agree with your comment on the RVWMO memory model requirement. Since this requirement is for the OS-A platform, providing an additional level of clarity will help since all implementations