lkml.org 
[lkml]   [2017]   [Mar]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] kvm: pass the virtual SEI syndrome to guest OS
    Hi Christoffer,

    (CC: Leif and Achin who know more about how UEFI fits into this picture)

    On 21/03/17 19:39, Christoffer Dall wrote:
    > On Tue, Mar 21, 2017 at 07:11:44PM +0000, James Morse wrote:
    >> On 21/03/17 11:34, Christoffer Dall wrote:
    >>> On Tue, Mar 21, 2017 at 02:32:29PM +0800, gengdongjiu wrote:
    >>>> On 2017/3/20 23:08, James Morse wrote:
    >>>>>>>> On 20/03/17 07:55, Dongjiu Geng wrote:
    >>>>>>>>> In the RAS implementation, hardware pass the virtual SEI
    >>>>>>>>> syndrome information through the VSESR_EL2, so set the virtual
    >>>>>>>>> SEI syndrome using physical SEI syndrome el2_elr to pass to
    >>>>>>>>> the guest OS
    >>>>>
    >>>>> How does this work with firmware first?
    >>>>
    >>>> I explained it in previous mail about the work flow.
    >>>
    >>> When delivering and reporting SEIs to the VM, should this happen
    >>> directly to the OS running in the VM, or to the guest firmware (e.g.
    >>> UEFI) running in the VM as well?
    >>
    >> 'firmware first' is the ACPI specs name for x86's BIOS or management-mode
    >> handling the error. On arm64 we have multiple things called firmware, so the
    >> name might be more confusing than helpful.
    >>
    >> As far as I understand it, firmware here refers to the secure-world and EL3.
    >> Something like ATF can use SCR_EL3.EA to claim SErrors and external aborts,
    >> routing them to EL3 where secure platform specific firmware generates CPER records.
    >> For a guest, Qemu takes the role of this EL3-firmware.
    >>
    > Thanks for the clarification. So UEFI in the VM would not be involved
    > in this at all?

    On the host, part of UEFI is involved to generate the CPER records.
    In a guest?, I don't know.
    Qemu could generate the records, or drive some other component to do it.

    Leif and Achin are the people with the UEFI/bigger picture.


    > My confusion here comes from not thinking about QEMU or KVM as firmware,
    > but as the machine, so it would be sort of like the functionality is
    > baked into hardware rather than firmware.
    >
    > Note that to the VM, the environment will look like hardware without EL3
    > and without a secure world, so any software assuming there's something
    > 'hidden' behind the available non-secure modes must not decide to
    > disable features if discovering the lack of a secure world.


    Thanks,

    James

    \
     
     \ /
      Last update: 2017-03-28 12:50    [W:3.949 / U:0.048 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site