Date   

Invitation: Ad-hoc ACPI ECR Review meeting - Part 2 @ Mon Jul 4, 2022 9:30pm - 10:30pm (IST) (tech-unixplatformspec@lists.riscv.org)

Sunil V L
 

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 Meet
Join by phone
(US) +1 484-641-8341 (PIN: 271065128)
Calendar
tech-unixplatformspec@...
Who
sunilvl@... - organizer
tech-unixplatformspec@...
tech-os-a-see@...
tech-aia@...
Atish Kumar Patra
furquan@...
apatel@...
ksankaran@...
Hi All,

This is the second part of the ACPI ECR review meeting to cover remaining things. Many thanks to the people who joined the first meeting and provided valuable feedback. Let us meet again and discuss further.

Meeting Info:
  • Meeting link: https://zoom.us/j/7237830759    
  • Passcode: 741796    
  • Join link: https://zoom.us/j/7237830759?pwd=bGE2QkMwNm1xclF4SDI1cll0Mk1LQT09 
  • Going (tech-unixplatformspec@...)?   Yes - Maybe - No    more options »

    Invitation from Google Calendar

    You are receiving this courtesy email at the account tech-unixplatformspec@... because you are an attendee of this event.

    To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar.

    Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn More.


    Re: [RISC-V][tech-os-a-see] Review request for ACPI ECRs

    Sunil V L
     

    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: https://zoom.us/j/7237830759?pwd=bGE2QkMwNm1xclF4SDI1cll0Mk1LQT09

    Thanks
    Sunil

    On Fri, Jun 24, 2022 at 03:42:14PM +0400, Furquan Shaikh wrote:
    On Fri, Jun 24, 2022 at 8:31 AM Sunil V L <sunilvl@...> wrote:

    On Thu, Jun 23, 2022 at 11:30:28PM +0400, Furquan Shaikh wrote:
    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 for defining
    these structures over a meeting with interested RISC-V members. What
    do you think?
    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.
    Sounds good. Thanks, Sunil!

    - Furquan


    Thanks!
    Sunil


    Thanks,
    Furquan

    On Tue, Jun 21, 2022 at 9:48 PM Sunil V L <sunilvl@...> wrote:

    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 -
    https://docs.google.com/document/d/13YdZzUv0mRHBotdy4Qjqrzb-83mjM31AyEXXfgodcNw/edit?usp=sharing

    2) Add new RISC-V Hart Capabilities Table (RHCT).
    https://docs.google.com/document/d/1-hQMzSNTEfNqudIENhGxrrb0Yr5MEo4NcZwXZlvdx6k/edit?usp=sharing

    3) Add AIA interrupt controllers in MADT table
    https://docs.google.com/document/d/1rbdXsON4OMJ0QB3UvkfkIa8hdySbWArIKqPRUli7AU0/edit?usp=sharing

    First two ECRs do not have a dependency on any RVI specs which are not
    frozen. But the third ECR has a dependency on AIA spec to be frozen.
    Hence this AIA ECR will NOT be sent to UEFI forum until AIA spec is frozen.

    The PoC for these ECRs is complete and ACPI enabled Linux boots on qemu
    platform. Below are links to the source code for the PoC.
    qemu - https://github.com/ventanamicro/qemu/tree/dev-upstream
    edk2 - https://github.com/ventanamicro/edk2/tree/dev-upstream
    edk2-platforms - https://github.com/ventanamicro/edk2-platforms/tree/dev-upstream
    linux - https://github.com/ventanamicro/linux/tree/dev-upstream

    You can find how to build and test these changes in this link -
    https://github.com/riscv-non-isa/riscv-acpi/wiki/PoC-:-How-to-build-and-test-ACPI-enabled-kernel

    You can provide the feedback by commenting in the document itself. I am
    hoping to send at least first two ECRs to UEFI forum by 8th August 2022.
    So, appreciate your help to improve these ECRs before 4th August 2022
    (45 days from today).

    Feel free to reach out if you have any questions.

    Thanks!
    Sunil








    Re: SBI Debug Console Extension Proposal (Draft v2)

    Ved Shanbhogue
     

    On Mon, Jun 27, 2022 at 06:58:15PM +0530, Anup Patel wrote:

    The rationale is that for M-mode the memory type is always defined by
    PMA(s) so if supervisor-mode software overrides memory type using
    Svpbmt then M-mode firmware will not see same contents as the
    supervisor-mode software.
    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 using different cachability attribute than the PMA then a loss of coherence or unexpected memory ordering may occur and the invoking software should follow the rules and sequences defined in the Svpbmt specification to prevent the loss of coherence and memory ordering.

    This does not place a restriction but warns against the issue and
    points to the right sequence if there is a legitimate reason to do it.

    This should not be specific to this function but applicable to any
    function that the SBI defines with a memory operand and so could be
    stated more generally in the SBI specification.

    regards
    ved


    Re: SBI Debug Console Extension Proposal (Draft v2)

    Anup Patel
     

    On Mon, Jun 27, 2022 at 6:16 PM Ved Shanbhogue <ved@...> wrote:

    On Mon, Jun 27, 2022 at 05:38:43PM +0530, Anup Patel wrote:
    Also, a system might be partitioned into domains so a supervisor software
    running in a particular domain can only pass addresses accessible in that
    domain.
    So domain is a new term which is not presently defined in the privileged
    specification or in the SBI specification.
    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 also implement some kind of
    system level partitioning.


    I think I get what you may be stating here i.e., M-mode may configure/
    reconfigure PMPs to restrict the physical addresses that are accessible to
    the supervisor-mode. Perhaps a future Smpu extension may add to this mix.

    To avoid inventing a new term, we could reword #1 to state that the physical
    address must be accessible, as determined by the PMP and/or PMA rules, to the
    supervisor mode software invoking this SBI function.

    To further restrict this perhaps say "accessible to read"? As we may not want
    execute-only to be allowed by this extension.
    I mostly agree with your wording. Considering hypervisors and future memory
    protection ISA extensions, let's avoid using terms PMP.

    For #1, we can say:
    The SBI implementation MUST check that the supervisor-mode software
    is allowed to read the specified physical address range on the calling HART.



    For OpenSBI, we have domain regions so OpenSBI will check the address
    against regions of the domain assigned to calling HART.
    Since "domain" is a concept that is not defined by either the privilege
    specification or the SBI specification we may want to avoid using that
    term (or add a definition).
    The term "domain" was only in the context of OpenSBI. We should not use
    this term in the SBI specification.


    This is more a requirement on the supervisor-mode software because
    we might have a system with Svpbmt so on such system supervisor-mode
    should not pass an address which is mapped as non-cacheable in the
    page table.
    This is confusing since the description states that the parameter is a
    physical address but the later comment states its a virtual address
    and the memory type override using page-based memory type provided by
    the virtual memory system is allowed. Could we clarify if its a physical
    address - in which case only the coherence and cachability PMA should
    provide the memory type - or a virtual address in which case page-based
    memory type override is possible.

    Further, a brief explanation about why cachability matters for this
    extension would be useful. Is this trying to imply some kind of early
    boot execution where caches may be placed in a special mode that allows
    operation when main memory is not available.
    I agree the #2 requirement is not clear enough.

    For #2, we can say:
    The supervisor-mode software MUST not override the memory type of
    specified physical address range using page-based memory types.

    The rationale is that for M-mode the memory type is always defined by
    PMA(s) so if supervisor-mode software overrides memory type using
    Svpbmt then M-mode firmware will not see same contents as the
    supervisor-mode software.

    Regards,
    Anup


    Re: SBI Debug Console Extension Proposal (Draft v2)

    Ved Shanbhogue
     

    On Mon, Jun 27, 2022 at 05:38:43PM +0530, Anup Patel wrote:
    Also, a system might be partitioned into domains so a supervisor software
    running in a particular domain can only pass addresses accessible in that
    domain.
    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 PMPs to restrict the physical addresses that are accessible to the supervisor-mode. Perhaps a future Smpu extension may add to this mix.

    To avoid inventing a new term, we could reword #1 to state that the physical address must be accessible, as determined by the PMP and/or PMA rules, to the
    supervisor mode software invoking this SBI function.

    To further restrict this perhaps say "accessible to read"? As we may not want execute-only to be allowed by this extension.


    For OpenSBI, we have domain regions so OpenSBI will check the address
    against regions of the domain assigned to calling HART.
    Since "domain" is a concept that is not defined by either the privilege
    specification or the SBI specification we may want to avoid using that
    term (or add a definition).

    This is more a requirement on the supervisor-mode software because
    we might have a system with Svpbmt so on such system supervisor-mode
    should not pass an address which is mapped as non-cacheable in the
    page table.
    This is confusing since the description states that the parameter is a
    physical address but the later comment states its a virtual address
    and the memory type override using page-based memory type provided by
    the virtual memory system is allowed. Could we clarify if its a physical
    address - in which case only the coherence and cachability PMA should provide the memory type - or a virtual address in which case page-based memory type override is possible.

    Further, a brief explanation about why cachability matters for this extension would be useful. Is this trying to imply some kind of early
    boot execution where caches may be placed in a special mode that allows
    operation when main memory is not available.

    regards
    ved


    Re: SBI Debug Console Extension Proposal (Draft v2)

    Heinrich Schuchardt
     

    On 6/27/22 14:08, Anup Patel wrote:
    On Mon, Jun 27, 2022 at 4:45 PM Heinrich Schuchardt <xypron.glpk@...> wrote:

    On 6/27/22 10:46, Anup Patel wrote:
    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 the legacy SBI v0.1
    putchar() and getchar() calls. These legacy SBI v0.1 calls are
    now disabled by default in Linux and will be eventually deprecated.
    We need a replacement at least for the SBI v0.1 putchar() which
    is widely used for early prints in various OSes and Bootloaders.
    2) The OS-A Platforms (or SEE) specification need to mandate
    a particular type of UART (8250, ns16550, or SiFive) as a standard
    way for boot-time early prints in supervisor-mode software. Using
    SBI debug console extension, the OS-A Platforms (or SEE)
    specifications don't need to mandate any type of UART.
    3) The legacy SBI v0.1 putchar() only supports printing one
    character at a time. For some of the hypervisors (particularly KVM),
    SBI based early prints (i.e. earlycon=sbi) is slow because each
    SBI v0.1 putchar() trap will be forwarded to the KVM user-space
    (KVMTOOL or QEMU).

    In short, the SBI debug console extension defines a standard way
    for boot-time early prints in supervisor-mode software.

    Please review it and provide your feedback.

    Regards,
    Anup

    SBI Debug Console Extension (EID #0x4442434E "DBCN")
    ====================================================

    The debug console extension defines a generic mechanism for boot-time
    early prints from supervisor-mode software which allows users to catch
    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.
    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 fact, both HS-mode and VS-mode are actually supervisor-mode with
    different capabilities.


    How are systems treated that only have M-mode and U-mode?
    For systems with only M-mode and U-mode, there is no supervisor-mode
    hence there is no SBI on such systems. These are embedded-class
    systems which usually run some kind of RTOS.


    boot-time issues in supervisor-mode software.

    This extension replaces legacy console putchar (EID #0x01) extension
    and it is better in following ways:
    1) It follows the new calling convention defined for SBI v1.0
    (or higher).
    2) It allows supervisor software to print multiple characters
    in a single SBI call.

    If the underlying physical console has extra bits for error checking
    (or correction) then these extra bits should be handled by the
    SBI implementation.

    Function: Console Puts (FID #0)
    -------------------------------

    struct sbiret sbi_debug_console_puts(unsigned long addr_div_by_4,
    unsigned long num_chars)

    Print the string specified by the `addr_div_by_4` and `num_chars`
    parameters on the debug console. The `addr_div_by_4` parameter is
    the physical base address of the string right shifted by 2 whereas
    the `num_chars` parameter is the number of characters (or bytes) in
    the string.

    The memory pointed the `addr_div_by_4` and `num_chars` parameters
    must be:
    1) Accessible to supervisor-mode
    2) Cacheable and writable memory
    Accessibility by supervisor-mode is required due to security
    considerations: You should not be able to print out M-mode's secrets via
    S-mode software. This should be clearly stated.
    The point#1 tries to say this.
    Also, a system might be partitioned into domains so a supervisor software
    running in a particular domain can only pass addresses accessible in that
    domain.


    MUST an SBI implementation check this feature? Probably yes. How shall
    it be checked?
    It's up to the SBI implementation how to check this feature.
    As this is a security feature we should require:

    The SBI MUST check that the full memory range is read-accessible by the caller.

    For OpenSBI, we have domain regions so OpenSBI will check the address
    against regions of the domain assigned to calling HART.
    For KVM, the user-space tool (QEMU/KVMTOO) knows the guest physical
    address range of Guest RAM which can be used to validate the address.


    The SBI is not meant to change the string and therefore needs no write
    access. There is no reason to require that the memory should be
    writable. The string could reside in NOR flash.

    Caching may speed up the SBI code. But why should we require this
    specific memory region being cached?
    This is more a requirement on the supervisor-mode software because
    we might have a system with Svpbmt so on such system supervisor-mode
    should not pass an address which is mapped as non-cacheable in the
    page table.
    We can certainly re-word this requirement to:
    "Cacheable and readable memory"
    Here too we should make it clear if the SBI MUST or MAY check the property. I guess MAY is enough.

    Best regards

    Heinrich



    One of the replies to your v1 patch requested to have the same
    capabilities as putchar(): just pass a single character in a register.
    Should a second FID be added?
    It's pretty easy to print a single character using the proposed puts()
    call.
    For assembly source perspective, this will be just one extra instruction.
    Regards,
    Anup


    Best regards

    Heinrich


    This is a blocking SBI call and will only return after printing
    all characters of the string.

    Errors:
    SBI_SUCCESS - Characters printed successfully.
    SBI_ERR_INVALID_ADDRESS - The string pointed by `addr_div_by_4`
    and `num_chars` parameters is either not
    accessible to supervisor-mode or does not
    point to cacheable and writable memory.
    SBI_ERR_FAILED - Failed to print characters due to
    I/O errors.


    Re: SBI Debug Console Extension Proposal (Draft v2)

    Anup Patel
     

    On Mon, Jun 27, 2022 at 4:45 PM Heinrich Schuchardt <xypron.glpk@...> wrote:

    On 6/27/22 10:46, Anup Patel wrote:
    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 the legacy SBI v0.1
    putchar() and getchar() calls. These legacy SBI v0.1 calls are
    now disabled by default in Linux and will be eventually deprecated.
    We need a replacement at least for the SBI v0.1 putchar() which
    is widely used for early prints in various OSes and Bootloaders.
    2) The OS-A Platforms (or SEE) specification need to mandate
    a particular type of UART (8250, ns16550, or SiFive) as a standard
    way for boot-time early prints in supervisor-mode software. Using
    SBI debug console extension, the OS-A Platforms (or SEE)
    specifications don't need to mandate any type of UART.
    3) The legacy SBI v0.1 putchar() only supports printing one
    character at a time. For some of the hypervisors (particularly KVM),
    SBI based early prints (i.e. earlycon=sbi) is slow because each
    SBI v0.1 putchar() trap will be forwarded to the KVM user-space
    (KVMTOOL or QEMU).

    In short, the SBI debug console extension defines a standard way
    for boot-time early prints in supervisor-mode software.

    Please review it and provide your feedback.

    Regards,
    Anup

    SBI Debug Console Extension (EID #0x4442434E "DBCN")
    ====================================================

    The debug console extension defines a generic mechanism for boot-time
    early prints from supervisor-mode software which allows users to catch
    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.
    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 fact, both HS-mode and VS-mode are actually supervisor-mode with
    different capabilities.


    How are systems treated that only have M-mode and U-mode?
    For systems with only M-mode and U-mode, there is no supervisor-mode
    hence there is no SBI on such systems. These are embedded-class
    systems which usually run some kind of RTOS.


    boot-time issues in supervisor-mode software.

    This extension replaces legacy console putchar (EID #0x01) extension
    and it is better in following ways:
    1) It follows the new calling convention defined for SBI v1.0
    (or higher).
    2) It allows supervisor software to print multiple characters
    in a single SBI call.

    If the underlying physical console has extra bits for error checking
    (or correction) then these extra bits should be handled by the
    SBI implementation.

    Function: Console Puts (FID #0)
    -------------------------------

    struct sbiret sbi_debug_console_puts(unsigned long addr_div_by_4,
    unsigned long num_chars)

    Print the string specified by the `addr_div_by_4` and `num_chars`
    parameters on the debug console. The `addr_div_by_4` parameter is
    the physical base address of the string right shifted by 2 whereas
    the `num_chars` parameter is the number of characters (or bytes) in
    the string.

    The memory pointed the `addr_div_by_4` and `num_chars` parameters
    must be:
    1) Accessible to supervisor-mode
    2) Cacheable and writable memory
    Accessibility by supervisor-mode is required due to security
    considerations: You should not be able to print out M-mode's secrets via
    S-mode software. This should be clearly stated.
    The point#1 tries to say this.

    Also, a system might be partitioned into domains so a supervisor software
    running in a particular domain can only pass addresses accessible in that
    domain.


    MUST an SBI implementation check this feature? Probably yes. How shall
    it be checked?
    It's up to the SBI implementation how to check this feature.

    For OpenSBI, we have domain regions so OpenSBI will check the address
    against regions of the domain assigned to calling HART.

    For KVM, the user-space tool (QEMU/KVMTOO) knows the guest physical
    address range of Guest RAM which can be used to validate the address.


    The SBI is not meant to change the string and therefore needs no write
    access. There is no reason to require that the memory should be
    writable. The string could reside in NOR flash.

    Caching may speed up the SBI code. But why should we require this
    specific memory region being cached?
    This is more a requirement on the supervisor-mode software because
    we might have a system with Svpbmt so on such system supervisor-mode
    should not pass an address which is mapped as non-cacheable in the
    page table.

    We can certainly re-word this requirement to:
    "Cacheable and readable memory"


    One of the replies to your v1 patch requested to have the same
    capabilities as putchar(): just pass a single character in a register.
    Should a second FID be added?
    It's pretty easy to print a single character using the proposed puts()
    call.

    For assembly source perspective, this will be just one extra instruction.

    Regards,
    Anup


    Best regards

    Heinrich


    This is a blocking SBI call and will only return after printing
    all characters of the string.

    Errors:
    SBI_SUCCESS - Characters printed successfully.
    SBI_ERR_INVALID_ADDRESS - The string pointed by `addr_div_by_4`
    and `num_chars` parameters is either not
    accessible to supervisor-mode or does not
    point to cacheable and writable memory.
    SBI_ERR_FAILED - Failed to print characters due to
    I/O errors.


    Re: SBI Debug Console Extension Proposal (Draft v2)

    Heinrich Schuchardt
     

    On 6/27/22 10:46, Anup Patel wrote:
    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 the legacy SBI v0.1
    putchar() and getchar() calls. These legacy SBI v0.1 calls are
    now disabled by default in Linux and will be eventually deprecated.
    We need a replacement at least for the SBI v0.1 putchar() which
    is widely used for early prints in various OSes and Bootloaders.
    2) The OS-A Platforms (or SEE) specification need to mandate
    a particular type of UART (8250, ns16550, or SiFive) as a standard
    way for boot-time early prints in supervisor-mode software. Using
    SBI debug console extension, the OS-A Platforms (or SEE)
    specifications don't need to mandate any type of UART.
    3) The legacy SBI v0.1 putchar() only supports printing one
    character at a time. For some of the hypervisors (particularly KVM),
    SBI based early prints (i.e. earlycon=sbi) is slow because each
    SBI v0.1 putchar() trap will be forwarded to the KVM user-space
    (KVMTOOL or QEMU).

    In short, the SBI debug console extension defines a standard way
    for boot-time early prints in supervisor-mode software.

    Please review it and provide your feedback.

    Regards,
    Anup

    SBI Debug Console Extension (EID #0x4442434E "DBCN")
    ====================================================

    The debug console extension defines a generic mechanism for boot-time
    early prints from supervisor-mode software which allows users to catch
    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 U-mode?

    boot-time issues in supervisor-mode software.

    This extension replaces legacy console putchar (EID #0x01) extension
    and it is better in following ways:
    1) It follows the new calling convention defined for SBI v1.0
    (or higher).
    2) It allows supervisor software to print multiple characters
    in a single SBI call.

    If the underlying physical console has extra bits for error checking
    (or correction) then these extra bits should be handled by the
    SBI implementation.

    Function: Console Puts (FID #0)
    -------------------------------

    struct sbiret sbi_debug_console_puts(unsigned long addr_div_by_4,
    unsigned long num_chars)

    Print the string specified by the `addr_div_by_4` and `num_chars`
    parameters on the debug console. The `addr_div_by_4` parameter is
    the physical base address of the string right shifted by 2 whereas
    the `num_chars` parameter is the number of characters (or bytes) in
    the string.

    The memory pointed the `addr_div_by_4` and `num_chars` parameters
    must be:
    1) Accessible to supervisor-mode
    2) Cacheable and writable memory
    Accessibility by supervisor-mode is required due to security
    considerations: You should not be able to print out M-mode's secrets via
    S-mode software. This should be clearly stated.

    MUST an SBI implementation check this feature? Probably yes. How shall
    it be checked?

    The SBI is not meant to change the string and therefore needs no write
    access. There is no reason to require that the memory should be
    writable. The string could reside in NOR flash.

    Caching may speed up the SBI code. But why should we require this
    specific memory region being cached?

    One of the replies to your v1 patch requested to have the same
    capabilities as putchar(): just pass a single character in a register.
    Should a second FID be added?

    Best regards

    Heinrich


    This is a blocking SBI call and will only return after printing
    all characters of the string.

    Errors:
    SBI_SUCCESS - Characters printed successfully.
    SBI_ERR_INVALID_ADDRESS - The string pointed by `addr_div_by_4`
    and `num_chars` parameters is either not
    accessible to supervisor-mode or does not
    point to cacheable and writable memory.
    SBI_ERR_FAILED - Failed to print characters due to
    I/O errors.


    SBI Debug Console Extension Proposal (Draft v2)

    Anup Patel
     

    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 the legacy SBI v0.1
    putchar() and getchar() calls. These legacy SBI v0.1 calls are
    now disabled by default in Linux and will be eventually deprecated.
    We need a replacement at least for the SBI v0.1 putchar() which
    is widely used for early prints in various OSes and Bootloaders.
    2) The OS-A Platforms (or SEE) specification need to mandate
    a particular type of UART (8250, ns16550, or SiFive) as a standard
    way for boot-time early prints in supervisor-mode software. Using
    SBI debug console extension, the OS-A Platforms (or SEE)
    specifications don't need to mandate any type of UART.
    3) The legacy SBI v0.1 putchar() only supports printing one
    character at a time. For some of the hypervisors (particularly KVM),
    SBI based early prints (i.e. earlycon=sbi) is slow because each
    SBI v0.1 putchar() trap will be forwarded to the KVM user-space
    (KVMTOOL or QEMU).

    In short, the SBI debug console extension defines a standard way
    for boot-time early prints in supervisor-mode software.

    Please review it and provide your feedback.

    Regards,
    Anup

    SBI Debug Console Extension (EID #0x4442434E "DBCN")
    ====================================================

    The debug console extension defines a generic mechanism for boot-time
    early prints from supervisor-mode software which allows users to catch
    boot-time issues in supervisor-mode software.

    This extension replaces legacy console putchar (EID #0x01) extension
    and it is better in following ways:
    1) It follows the new calling convention defined for SBI v1.0
    (or higher).
    2) It allows supervisor software to print multiple characters
    in a single SBI call.

    If the underlying physical console has extra bits for error checking
    (or correction) then these extra bits should be handled by the
    SBI implementation.

    Function: Console Puts (FID #0)
    -------------------------------

    struct sbiret sbi_debug_console_puts(unsigned long addr_div_by_4,
    unsigned long num_chars)

    Print the string specified by the `addr_div_by_4` and `num_chars`
    parameters on the debug console. The `addr_div_by_4` parameter is
    the physical base address of the string right shifted by 2 whereas
    the `num_chars` parameter is the number of characters (or bytes) in
    the string.

    The memory pointed the `addr_div_by_4` and `num_chars` parameters
    must be:
    1) Accessible to supervisor-mode
    2) Cacheable and writable memory

    This is a blocking SBI call and will only return after printing
    all characters of the string.

    Errors:
    SBI_SUCCESS - Characters printed successfully.
    SBI_ERR_INVALID_ADDRESS - The string pointed by `addr_div_by_4`
    and `num_chars` parameters is either not
    accessible to supervisor-mode or does not
    point to cacheable and writable memory.
    SBI_ERR_FAILED - Failed to print characters due to
    I/O errors.


    Re: [RISC-V][tech-os-a-see] Review request for ACPI ECRs

    Furquan Shaikh
     

    On Fri, Jun 24, 2022 at 8:31 AM Sunil V L <sunilvl@...> wrote:

    On Thu, Jun 23, 2022 at 11:30:28PM +0400, Furquan Shaikh wrote:
    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 for defining
    these structures over a meeting with interested RISC-V members. What
    do you think?
    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.
    Sounds good. Thanks, Sunil!

    - Furquan


    Thanks!
    Sunil


    Thanks,
    Furquan

    On Tue, Jun 21, 2022 at 9:48 PM Sunil V L <sunilvl@...> wrote:

    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 -
    https://docs.google.com/document/d/13YdZzUv0mRHBotdy4Qjqrzb-83mjM31AyEXXfgodcNw/edit?usp=sharing

    2) Add new RISC-V Hart Capabilities Table (RHCT).
    https://docs.google.com/document/d/1-hQMzSNTEfNqudIENhGxrrb0Yr5MEo4NcZwXZlvdx6k/edit?usp=sharing

    3) Add AIA interrupt controllers in MADT table
    https://docs.google.com/document/d/1rbdXsON4OMJ0QB3UvkfkIa8hdySbWArIKqPRUli7AU0/edit?usp=sharing

    First two ECRs do not have a dependency on any RVI specs which are not
    frozen. But the third ECR has a dependency on AIA spec to be frozen.
    Hence this AIA ECR will NOT be sent to UEFI forum until AIA spec is frozen.

    The PoC for these ECRs is complete and ACPI enabled Linux boots on qemu
    platform. Below are links to the source code for the PoC.
    qemu - https://github.com/ventanamicro/qemu/tree/dev-upstream
    edk2 - https://github.com/ventanamicro/edk2/tree/dev-upstream
    edk2-platforms - https://github.com/ventanamicro/edk2-platforms/tree/dev-upstream
    linux - https://github.com/ventanamicro/linux/tree/dev-upstream

    You can find how to build and test these changes in this link -
    https://github.com/riscv-non-isa/riscv-acpi/wiki/PoC-:-How-to-build-and-test-ACPI-enabled-kernel

    You can provide the feedback by commenting in the document itself. I am
    hoping to send at least first two ECRs to UEFI forum by 8th August 2022.
    So, appreciate your help to improve these ECRs before 4th August 2022
    (45 days from today).

    Feel free to reach out if you have any questions.

    Thanks!
    Sunil








    Invitation: Ad-hoc ACPI ECR Review meeting @ Mon Jun 27, 2022 9:30pm - 10:30pm (IST) (tech-unixplatformspec@lists.riscv.org)

    Sunil V L
     

    You have been invited to the following event.

    Ad-hoc ACPI ECR Review meeting

    When
    Mon Jun 27, 2022 9:30pm – 10:30pm India Standard Time - Kolkata
    Joining info
    Join with Google Meet
    Join by phone
    (US) +1 567-443-0759 (PIN: 987181039)
    Calendar
    tech-unixplatformspec@...
    Who
    sunilvl@... - organizer
    tech-unixplatformspec@...
    tech-os-a-see@...
    Atish Kumar Patra
    furquan@...
    apatel@...
    tech.meetings@...
    Hi All,

    This is an ad-hoc meeting to go over the ACPI ECR proposals. Will update the zoom link before the meeting.

    Thanks
    Sunil

    Going (tech-unixplatformspec@...)?   Yes - Maybe - No    more options »

    Invitation from Google Calendar

    You are receiving this courtesy email at the account tech-unixplatformspec@... because you are an attendee of this event.

    To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar.

    Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn More.


    Re: [RISC-V][tech-os-a-see] Review request for ACPI ECRs

    Sunil V L
     

    On Thu, Jun 23, 2022 at 11:30:28PM +0400, Furquan Shaikh wrote:
    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 for defining
    these structures over a meeting with interested RISC-V members. What
    do you think?
    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


    Thanks,
    Furquan

    On Tue, Jun 21, 2022 at 9:48 PM Sunil V L <sunilvl@...> wrote:

    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 -
    https://docs.google.com/document/d/13YdZzUv0mRHBotdy4Qjqrzb-83mjM31AyEXXfgodcNw/edit?usp=sharing

    2) Add new RISC-V Hart Capabilities Table (RHCT).
    https://docs.google.com/document/d/1-hQMzSNTEfNqudIENhGxrrb0Yr5MEo4NcZwXZlvdx6k/edit?usp=sharing

    3) Add AIA interrupt controllers in MADT table
    https://docs.google.com/document/d/1rbdXsON4OMJ0QB3UvkfkIa8hdySbWArIKqPRUli7AU0/edit?usp=sharing

    First two ECRs do not have a dependency on any RVI specs which are not
    frozen. But the third ECR has a dependency on AIA spec to be frozen.
    Hence this AIA ECR will NOT be sent to UEFI forum until AIA spec is frozen.

    The PoC for these ECRs is complete and ACPI enabled Linux boots on qemu
    platform. Below are links to the source code for the PoC.
    qemu - https://github.com/ventanamicro/qemu/tree/dev-upstream
    edk2 - https://github.com/ventanamicro/edk2/tree/dev-upstream
    edk2-platforms - https://github.com/ventanamicro/edk2-platforms/tree/dev-upstream
    linux - https://github.com/ventanamicro/linux/tree/dev-upstream

    You can find how to build and test these changes in this link -
    https://github.com/riscv-non-isa/riscv-acpi/wiki/PoC-:-How-to-build-and-test-ACPI-enabled-kernel

    You can provide the feedback by commenting in the document itself. I am
    hoping to send at least first two ECRs to UEFI forum by 8th August 2022.
    So, appreciate your help to improve these ECRs before 4th August 2022
    (45 days from today).

    Feel free to reach out if you have any questions.

    Thanks!
    Sunil








    Re: [RISC-V][tech-os-a-see] Review request for ACPI ECRs

    Furquan Shaikh
     

    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 for defining
    these structures over a meeting with interested RISC-V members. What
    do you think?

    Thanks,
    Furquan

    On Tue, Jun 21, 2022 at 9:48 PM Sunil V L <sunilvl@...> wrote:

    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 -
    https://docs.google.com/document/d/13YdZzUv0mRHBotdy4Qjqrzb-83mjM31AyEXXfgodcNw/edit?usp=sharing

    2) Add new RISC-V Hart Capabilities Table (RHCT).
    https://docs.google.com/document/d/1-hQMzSNTEfNqudIENhGxrrb0Yr5MEo4NcZwXZlvdx6k/edit?usp=sharing

    3) Add AIA interrupt controllers in MADT table
    https://docs.google.com/document/d/1rbdXsON4OMJ0QB3UvkfkIa8hdySbWArIKqPRUli7AU0/edit?usp=sharing

    First two ECRs do not have a dependency on any RVI specs which are not
    frozen. But the third ECR has a dependency on AIA spec to be frozen.
    Hence this AIA ECR will NOT be sent to UEFI forum until AIA spec is frozen.

    The PoC for these ECRs is complete and ACPI enabled Linux boots on qemu
    platform. Below are links to the source code for the PoC.
    qemu - https://github.com/ventanamicro/qemu/tree/dev-upstream
    edk2 - https://github.com/ventanamicro/edk2/tree/dev-upstream
    edk2-platforms - https://github.com/ventanamicro/edk2-platforms/tree/dev-upstream
    linux - https://github.com/ventanamicro/linux/tree/dev-upstream

    You can find how to build and test these changes in this link -
    https://github.com/riscv-non-isa/riscv-acpi/wiki/PoC-:-How-to-build-and-test-ACPI-enabled-kernel

    You can provide the feedback by commenting in the document itself. I am
    hoping to send at least first two ECRs to UEFI forum by 8th August 2022.
    So, appreciate your help to improve these ECRs before 4th August 2022
    (45 days from today).

    Feel free to reach out if you have any questions.

    Thanks!
    Sunil





    Review request for ACPI ECRs

    Sunil V L
     

    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 -
    https://docs.google.com/document/d/13YdZzUv0mRHBotdy4Qjqrzb-83mjM31AyEXXfgodcNw/edit?usp=sharing

    2) Add new RISC-V Hart Capabilities Table (RHCT).
    https://docs.google.com/document/d/1-hQMzSNTEfNqudIENhGxrrb0Yr5MEo4NcZwXZlvdx6k/edit?usp=sharing

    3) Add AIA interrupt controllers in MADT table
    https://docs.google.com/document/d/1rbdXsON4OMJ0QB3UvkfkIa8hdySbWArIKqPRUli7AU0/edit?usp=sharing

    First two ECRs do not have a dependency on any RVI specs which are not
    frozen. But the third ECR has a dependency on AIA spec to be frozen.
    Hence this AIA ECR will NOT be sent to UEFI forum until AIA spec is frozen.

    The PoC for these ECRs is complete and ACPI enabled Linux boots on qemu
    platform. Below are links to the source code for the PoC.
    qemu - https://github.com/ventanamicro/qemu/tree/dev-upstream
    edk2 - https://github.com/ventanamicro/edk2/tree/dev-upstream
    edk2-platforms - https://github.com/ventanamicro/edk2-platforms/tree/dev-upstream
    linux - https://github.com/ventanamicro/linux/tree/dev-upstream

    You can find how to build and test these changes in this link -
    https://github.com/riscv-non-isa/riscv-acpi/wiki/PoC-:-How-to-build-and-test-ACPI-enabled-kernel

    You can provide the feedback by commenting in the document itself. I am
    hoping to send at least first two ECRs to UEFI forum by 8th August 2022.
    So, appreciate your help to improve these ECRs before 4th August 2022
    (45 days from today).

    Feel free to reach out if you have any questions.

    Thanks!
    Sunil


    Re: [RISC-V][tech-os-a-see] Call for Candidates - OS-A SEE TG

    Darius Rad
     

    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 involved with RISC-V since 2013, contributing to the RISC-V
    port of various software projects and working on Bluespec hardware and
    software products centered on RISC-V. My past experience includes embedded
    system software and hardware development and processor design.

    I would like to help facilitate making the OS-A SEE (or whatever it gets
    called) specification something practical and useful as well as seeing it
    through to ratification in a timely manner.

    Thank you for the consideration.

    // darius

    On Thu, May 12, 2022 at 12:58:25PM -0600, Aaron Durbin wrote:
    All,

    As per the policy governing chairs and vice chairs, we are holding a call
    for candidates for the positions of CHAIR and VICE-CHAIR for the OS-A SEE
    TG. To nominate yourself or another member of the community, please respond
    to this thread with a short biography of the candidate (less than 250
    words) as well as a statement of intent (less than 250 words).

    If both Chair and Vice-Chair are available, candidates may nominate for one
    or both roles.

    A diversity of ideas and contributions, one that originates from a diverse
    community, from all walks of life, cultures, countries, and skin colors—is
    vital for building sustainable and healthy open source communities.
    Individuals from diverse backgrounds inject new and innovative ideas to
    advance an inclusive and welcoming ecosystem for all. RISC-V is committed
    to building diverse and inclusive communities.

    This call for candidates will be open for 2 weeks, ending on May 26, 2022
    (inclusive).

    If you have any questions regarding this process please contact
    help@....

    The current approved charter by the Priv SW HC (nee Software HC) can be
    found here <https://github.com/riscv-admin/os-a-see/blob/main/CHARTER.md>.

    Kind regard,
    Aaron Durbin





    Re: SBI changes

    atishp@...
     

    On Mon, Jun 6, 2022 at 8:42 AM Stephano Cetola <stephano@...> wrote:

    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 changes to be "upstreamed but not
    released", and allow specifications to go to Freeze & Ratification
    Do you mean SBI spec changes are merged in the spec but the SBI spec
    is not frozen
    by itself ?

    while they wait for the SBI changes to be released in the next version
    of SBI.
    Release of the SBI specification - ratified version or frozen is fine ?
    As long as dependent specs can go into public review once SBI spec is
    frozen, that should be fine too.
    As SBI spec is a software spec, a PoC implementation is the most
    critical step here.

    This is no different than the upstreaming of things like GCC today. We
    could make these changes to the process without changing the policy.
    (no vote needed)

    Cheers,
    Stephano

    On Thu, Jun 2, 2022 at 8:06 AM mark <markhimelstein@...> wrote:

    Just remember that something that depends on an SBI change can't get ratified until the SBI change is ratified.

    If there is a roll up, there still needs to a TG governing it or it needs to be a fast track with the committee governing it and there needs to be a rat plan.

    Mark

    On Thu, Jun 2, 2022 at 7:38 AM Anup Patel <apatel@...> wrote:

    On Thu, Jun 2, 2022 at 7:36 PM mark <markhimelstein@...> wrote:

    we have seen a number of SBI changes proposed (debug console, ap tee, ...).

    will there be one big rev ala priv 1.12, small fast tracks , something else?

    I also suggest that this either needs to be run out of the priv sw HC or convene a new TG. Can we conduct this conversation there (and create the appropriate group or committee mail aliases).
    My understanding is that different TGs or SIGs will propose their own
    SBI extensions. Once a set of changes for next SBI spec release are
    finalized, the SBI TG can collect all new SBI extensions and prepare a
    draft of the next SBI spec. It will be the responsibility of SBI TG to
    complete the ratification process.

    Is this understanding correct ?

    Regards,
    Anup


    Thanks
    Mark

    --------
    sent from a mobile device. please forgive any typos.







    Re: SBI changes

    Stephano Cetola
     

    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 changes to be "upstreamed but not
    released", and allow specifications to go to Freeze & Ratification
    while they wait for the SBI changes to be released in the next version
    of SBI.

    This is no different than the upstreaming of things like GCC today. We
    could make these changes to the process without changing the policy.
    (no vote needed)

    Cheers,
    Stephano

    On Thu, Jun 2, 2022 at 8:06 AM mark <markhimelstein@...> wrote:

    Just remember that something that depends on an SBI change can't get ratified until the SBI change is ratified.

    If there is a roll up, there still needs to a TG governing it or it needs to be a fast track with the committee governing it and there needs to be a rat plan.

    Mark

    On Thu, Jun 2, 2022 at 7:38 AM Anup Patel <apatel@...> wrote:

    On Thu, Jun 2, 2022 at 7:36 PM mark <markhimelstein@...> wrote:

    we have seen a number of SBI changes proposed (debug console, ap tee, ...).

    will there be one big rev ala priv 1.12, small fast tracks , something else?

    I also suggest that this either needs to be run out of the priv sw HC or convene a new TG. Can we conduct this conversation there (and create the appropriate group or committee mail aliases).
    My understanding is that different TGs or SIGs will propose their own
    SBI extensions. Once a set of changes for next SBI spec release are
    finalized, the SBI TG can collect all new SBI extensions and prepare a
    draft of the next SBI spec. It will be the responsibility of SBI TG to
    complete the ratification process.

    Is this understanding correct ?

    Regards,
    Anup


    Thanks
    Mark

    --------
    sent from a mobile device. please forgive any typos.




    Re: SBI Debug Console Extension Proposal (Draft v1)

    Darius Rad
     

    On Wed, Jun 01, 2022 at 09:47:32PM +0530, Anup Patel wrote:

    Debug Console Extension (EID #0x4442434E "DBCN")
    ================================================

    The debug console extension defines a generic mechanism for boot-time
    early prints from supervisor-mode software which allows users to catch
    boot-time issues in supervisor-mode software.

    This extension replaces legacy console putchar (EID #0x01) extension
    and it is better in following ways:
    1) It follows the new calling convention defined for SBI v1.0
    (or higher).
    2) It is based on a shared memory area between SBI implementation
    and supervisor-mode software so multiple characters can be
    printed using a single SBI call.

    The supervisor-mode software must set the shared memory area before
    printing characters on the debug console. Also, all HARTs share the
    same shared memory area so only one HART needs to set it at boot-time.
    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 requirements and
    assumptions that influenced the design of the interface, but are not
    mentioned here. It is important to document such information, in order to
    have a constructive discussion now, and also to preserve such information
    for readers in the future who may not have the benefit of reading the
    mailing list discussions.

    // darius


    Re: [sig-hypervisors] [RISC-V] [tech-unixplatformspec] SBI Debug Console Extension Proposal (Draft v1)

    Schwarz, Konrad <konrad.schwarz@...>
     

    -----Original Message-----
    From: Alistair Francis <Alistair.Francis@...>
    Sent: Friday, June 3, 2022 10:47
    Consider the case where we have more VMs than physical UARTs -- this
    will actually be the norm in most deployments.
    In this case you should use virtIO or some other more powerful
    interface


    (To counter the argument that the hypervisor can provide virtual
    UARTs
    for its guests, note that a dedicated para-virtualized interface is
    much more
    efficient than trapping individual memory accesses to simulated HW
    registers).
    Agreed, but tha seems up to the Hypervisor to implement an effient
    virtual UART implementation. For example the Xen HYPERVISOR_console_io
    that Stefano mentioned earlier. Plus then we can leverage existing
    implementations insted of inveting a another virtual serial device.
    But this makes it incumbent on each hypervisor to provide such an
    interface, and requires each OS to provide drivers for each
    hypervisor it knows about. You then have an N:M situation,
    which is bad for the RISC-V platform.

    By making the interface a bit richer, as discussed in my earlier
    proposal,
    a hypervisor can cover a much larger set of use cases.
    Which we also then need to support in M-mode firmware. The more complex
    the firmware becomes the more exposed it is.
    The same argument applies to hypervisors. What fundamental difference
    between M-mode and HS-mode software is there that makes the risk
    so much different?

    An implementation wishing to minimize its responsibilities can
    always return run-time errors for functionality it does not
    wish to support.

    --
    Konrad


    Re: [sig-hypervisors] [RISC-V] [tech-unixplatformspec] SBI Debug Console Extension Proposal (Draft v1)

    Alistair Francis
     

    On Fri, 2022-06-03 at 07:49 +0000, Schwarz, Konrad wrote:

    From:
    sig-hypervisors@... <sig-hypervisors@...>
    On Behalf Of Anup Patel via
    lists.riscv.org
    Sent: Friday, June 3, 2022 5:01
    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 replacement. This putchar() was being used in various cases
    for early prints from OSes and bootloaders.

    The SBI debug console extension is an attempt to replace the legacy
    SBI v0.1 putchar(). The use of shared memory in this proposal is
    motivated by the need to allow users to print multiple characters
    in
    one SBI call.
    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.
    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 instead just pass an
    address and size to print.


    The legacy SBI v0.1 also had a getchar() call which is deprecated
    and
    does not need any newer SBI call replacing it because it is
    expected
    all platforms (including virtual platforms emulated by hypervisors)
    will
    have a proper interrupt driver console for supervisor software. The
    proposed SBI debug console extension only tries to provide a
    solution
    for early prints.
    Consider the case where we have more VMs than physical UARTs -- this
    will actually be the norm in most deployments.
    In this case you should use virtIO or some other more powerful
    interface


    (To counter the argument that the hypervisor can provide virtual
    UARTs
    for its guests, note that a dedicated para-virtualized interface is
    much more
    efficient than trapping individual memory accesses to simulated HW
    registers).
    Agreed, but tha seems up to the Hypervisor to implement an effient
    virtual UART implementation. For example the Xen HYPERVISOR_console_io
    that Stefano mentioned earlier. Plus then we can leverage existing
    implementations insted of inveting a another virtual serial device.


    By making the interface a bit richer, as discussed in my earlier
    proposal,
    a hypervisor can cover a much larger set of use cases.
    Which we also then need to support in M-mode firmware. The more complex
    the firmware becomes the more exposed it is.

    Alistair



    --
    Konrad




    81 - 100 of 1847