Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1610552 > unrolled thread

Re: [PATCH] kvm: pass the virtual SEI syndrome to guest OS

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH] kvm: pass the virtual SEI syndrome to guest OS James Morse <james.morse@arm.com> - 2017-03-28 12:50 +0200
    Re: [PATCH] kvm: pass the virtual SEI syndrome to guest OS Christoffer Dall <cdall@linaro.org> - 2017-03-28 13:30 +0200
      Re: [PATCH] kvm: pass the virtual SEI syndrome to guest OS Peter Maydell <peter.maydell@linaro.org> - 2017-03-28 13:40 +0200
        Re: [PATCH] kvm: pass the virtual SEI syndrome to guest OS James Morse <james.morse@arm.com> - 2017-03-28 15:30 +0200
      Re: [PATCH] kvm: pass the virtual SEI syndrome to guest OS gengdongjiu <gengdongjiu@huawei.com> - 2017-03-28 14:20 +0200
        Re: [PATCH] kvm: pass the virtual SEI syndrome to guest OS James Morse <james.morse@arm.com> - 2017-03-28 15:50 +0200
          Re: [PATCH] kvm: pass the virtual SEI syndrome to guest OS gengdongjiu <gengdongjiu@huawei.com> - 2017-03-29 11:40 +0200
            Re: [PATCH] kvm: pass the virtual SEI syndrome to guest OS Laszlo Ersek <lersek@redhat.com> - 2017-03-29 14:00 +0200
              Re: [PATCH] kvm: pass the virtual SEI syndrome to guest OS "Michael S. Tsirkin" <mst@redhat.com> - 2017-03-29 15:00 +0200
                Re: [PATCH] kvm: pass the virtual SEI syndrome to guest OS Laszlo Ersek <lersek@redhat.com> - 2017-03-29 15:40 +0200
                  Re: [PATCH] kvm: pass the virtual SEI syndrome to guest OS Punit Agrawal <punit.agrawal@arm.com> - 2017-03-29 16:00 +0200
                  Re: [PATCH] kvm: pass the virtual SEI syndrome to guest OS "Michael S. Tsirkin" <mst@redhat.com> - 2017-03-29 16:00 +0200
              Re: [PATCH] kvm: pass the virtual SEI syndrome to guest OS gengdongjiu <gengdongjiu@huawei.com> - 2017-04-06 14:40 +0200
                Re: [PATCH] kvm: pass the virtual SEI syndrome to guest OS Laszlo Ersek <lersek@redhat.com> - 2017-04-06 21:00 +0200
                  Re: [PATCH] kvm: pass the virtual SEI syndrome to guest OS gengdongjiu <gengdongjiu@huawei.com> - 2017-04-07 05:00 +0200
                    Re: [PATCH] kvm: pass the virtual SEI syndrome to guest OS Laszlo Ersek <lersek@redhat.com> - 2017-04-07 11:30 +0200
            Re: [PATCH] kvm: pass the virtual SEI syndrome to guest OS gengdongjiu <gengdj.1984@gmail.com> - 2017-03-29 16:40 +0200
              Re: [PATCH] kvm: pass the virtual SEI syndrome to guest OS Christoffer Dall <cdall@linaro.org> - 2017-03-29 16:50 +0200
                Re: [PATCH] kvm: pass the virtual SEI syndrome to guest OS Laszlo Ersek <lersek@redhat.com> - 2017-03-29 17:40 +0200
                  Re: [PATCH] kvm: pass the virtual SEI syndrome to guest OS Christoffer Dall <cdall@linaro.org> - 2017-03-29 19:50 +0200
                    Re: [PATCH] kvm: pass the virtual SEI syndrome to guest OS gengdongjiu <gengdongjiu@huawei.com> - 2017-03-30 03:30 +0200
      Re: [PATCH] kvm: pass the virtual SEI syndrome to guest OS Christoffer Dall <cdall@linaro.org> - 2017-03-28 14:30 +0200
        Re: [PATCH] kvm: pass the virtual SEI syndrome to guest OS Christoffer Dall <cdall@linaro.org> - 2017-03-28 15:50 +0200

Page 2 of 2 — ← Prev page 1 [2]

#1612484

Hi Christoffer/Laszlo,

On 2017/3/30 1:44, Christoffer Dall wrote:
> On Wed, Mar 29, 2017 at 05:37:49PM +0200, Laszlo Ersek wrote:
>> On 03/29/17 16:48, Christoffer Dall wrote:
>>> On Wed, Mar 29, 2017 at 10:36:51PM +0800, gengdongjiu wrote:
>>>> 2017-03-29 18:36 GMT+08:00, Achin Gupta <achin.gupta@arm.com>:
>>
>>>>> Qemu is essentially fulfilling the role of secure firmware at the
>>>>> EL2/EL1 interface (as discussed with Christoffer below). So it
>>>>> should generate the CPER before injecting the error.
>>>>>
>>>>> This is corresponds to (1) above apart from notifying UEFI (I am
>>>>> assuming you mean guest UEFI). At this time, the guest OS already
>>>>> knows where to pick up the CPER from through the HEST. Qemu has
>>>>> to create the CPER and populate its address at the address
>>>>> exported in the HEST. Guest UEFI should not be involved in this 
>>>>> flow. Its job was to create the HEST at boot and that has been
>>>>> done by this stage.
>>>>
>>>> Sorry,  As I understand it, after Qemu generate the CPER table, it
>>>> should pass the CPER table to the guest UEFI, then Guest UEFI  place
>>>> this CPER table to the guest OS memory. In this flow, the Guest UEFI
>>>> should be involved, else the Guest OS can not see the CPER table.
>>>>
>>>
>>> I think you need to explain the "pass the CPER table to the guest UEFI"
>>> concept in terms of what really happens, step by step, and when you say
>>> "then Guest UEFI place the CPER table to the guest OS memory", I'm
>>> curious who is running what code on the hardware when doing that.
>>
>> I strongly suggest to keep the guest firmware's runtime involvement to
>> zero. Two reasons:
>>
>> (1) As you explained above (... which I conveniently snipped), when you
>> inject an interrupt to the guest, the handler registered for that
>> interrupt will come from the guest kernel.
>>
>> The only exception to this is when the platform provides a type of
>> interrupt whose handler can be registered and then locked down by the
>> firmware. On x86, this is the SMI.
>>
>> In practice though,
>> - in OVMF (x86), we only do synchronous (software-initiated) SMIs (for
>> privileged UEFI varstore access),
>> - and in ArmVirtQemu (ARM / aarch64), none of the management mode stuff
>> exists at all.
>>
>> I understand that the Platform Init 1.5 (or 1.6?) spec abstracted away
>> the MM (management mode) protocols from Intel SMM, but at this point
>> there is zero code in ArmVirtQemu for that. (And I'm unsure how much of
>> any eligible underlying hw emulation exists in QEMU.)
>>
>> So you can't get the guest firmware to react to the injected interrupt
>> without the guest OS coming between first.
>>
>> (2) Achin's description matches really-really closely what is possible,
>> and what should be done with QEMU, ArmVirtQemu, and the guest kernel.
>>
>> In any solution for this feature, the firmware has to reserve some
>> memory from the OS at boot. The current facilities we have enable this.
>> As I described previously, the ACPI linker/loader actions can be mapped
>> more or less 1:1 to Achin's design. From a practical perspective, you
>> really want to keep the guest firmware as dumb as possible (meaning: as
>> generic as possible), and keep the ACPI specifics to the QEMU and the
>> guest kernel sides.
>>
>> The error serialization actions -- the co-operation between guest kernel
>> and QEMU on the special memory areas -- that were mentioned earlier by
>> Michael and Punit look like a complication. But, IMO, they don't differ
>> from any other device emulation -- DMA actions in particular -- that
>> QEMU already does. Device models are what QEMU *does*. Read the command
>> block that the guest driver placed in guest memory, parse it, sanity
>> check it, verify it, execute it, write back the status code, inject an
>> interrupt (and/or let any polling guest driver notice it "soon after" --
>> use barriers as necessary).
>>
>> Thus, I suggest to rely on the generic ACPI linker/loader interface
>> (between QEMU and guest firmware) *only* to make the firmware lay out
>> stuff (= reserve buffers, set up pointers, install QEMU's ACPI tables)
>> *at boot*. Then, at runtime, let the guest kernel and QEMU (the "device
>> model") talk to each other directly. Keep runtime firmware involvement
>> to zero.
>>
>> You *really* don't want to debug three components at runtime, when you
>> can solve the thing with two. (Two components whose build systems won't
>> drive you mad, I should add.)
>>
>> IMO, Achin's design nailed it. We can do that.
>>
> I completely agree.
> 
> My questions were intended for gengdongjiu to clarify his/her 
> and clear up any misunderstandings between what Achin suggested and what
> he/she wrote.

  Achin and Laszlo's understanding are right. thanks for your suggestion.

> 
> Thanks,
> -Christoffer
> 
> .
> 

[toc] | [prev] | [next] | [standalone]

#1610640

On Tue, Mar 28, 2017 at 12:54:13PM +0100, Achin Gupta wrote:
> On Tue, Mar 28, 2017 at 01:23:28PM +0200, Christoffer Dall wrote:
> > On Tue, Mar 28, 2017 at 11:48:08AM +0100, James Morse wrote:
> > > 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.
> 
> +1
> 
> > > >>
> > > > 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.
> >
> > I think I am beginning to understand this a bit.  Since the guet UEFI
> > instance is specifically built for the machine it runs on, QEMU's virt
> > machine in this case, they could simply agree (by some contract) to
> > place the records at some specific location in memory, and if the guest
> > kernel asks its guest UEFI for that location, things should just work by
> > having logic in QEMU to process error reports and populate guest memory.
> >
> > Is this how others see the world too?
> 
> I think so!
> 
> AFAIU, the memory where CPERs will reside should be specified in a GHES entry in
> the HEST. Is this not the case with a guest kernel i.e. the guest UEFI creates a
> HEST for the guest Kernel?
> 
> If so, then the question is how the guest UEFI finds out where QEMU (acting as
> EL3 firmware) will populate the CPERs. This could either be a contract between
> the two or a guest DXE driver uses the MM_COMMUNICATE call (see [1]) to ask QEMU
> where the memory is.
> 
> This is the way I expect it to work at the EL3/EL2 boundary. So I am
> extrapolating it to the guest/hypervisor boundary. Do shout if I am missing
> anything.

No that sounds like a resonable comparison.

I'm not entirely sure what a HEST or GHES is, but I think the only place
where I'm still not clear is if when the guest kernel is notified of
errors does it (a) just traverse memory by following some pointers
(which it may have pre-loaded at boot from UEFI), or (b) run UEFI code
which can call into QEMU and generate error records on demand?

Thanks,
-Christoffer

[toc] | [prev] | [next] | [standalone]

#1610949

On Tue, Mar 28, 2017 at 02:24:55PM +0100, Achin Gupta wrote:
> On Tue, Mar 28, 2017 at 02:22:29PM +0200, Christoffer Dall wrote:
> > On Tue, Mar 28, 2017 at 12:54:13PM +0100, Achin Gupta wrote:
> > > On Tue, Mar 28, 2017 at 01:23:28PM +0200, Christoffer Dall wrote:
> > > > On Tue, Mar 28, 2017 at 11:48:08AM +0100, James Morse wrote:
> > > > > 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.
> > >
> > > +1
> > >
> > > > > >>
> > > > > > 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.
> > > >
> > > > I think I am beginning to understand this a bit.  Since the guet UEFI
> > > > instance is specifically built for the machine it runs on, QEMU's virt
> > > > machine in this case, they could simply agree (by some contract) to
> > > > place the records at some specific location in memory, and if the guest
> > > > kernel asks its guest UEFI for that location, things should just work by
> > > > having logic in QEMU to process error reports and populate guest memory.
> > > >
> > > > Is this how others see the world too?
> > >
> > > I think so!
> > >
> > > AFAIU, the memory where CPERs will reside should be specified in a GHES entry in
> > > the HEST. Is this not the case with a guest kernel i.e. the guest UEFI creates a
> > > HEST for the guest Kernel?
> > >
> > > If so, then the question is how the guest UEFI finds out where QEMU (acting as
> > > EL3 firmware) will populate the CPERs. This could either be a contract between
> > > the two or a guest DXE driver uses the MM_COMMUNICATE call (see [1]) to ask QEMU
> > > where the memory is.
> > >
> > > This is the way I expect it to work at the EL3/EL2 boundary. So I am
> > > extrapolating it to the guest/hypervisor boundary. Do shout if I am missing
> > > anything.
> >
> > No that sounds like a resonable comparison.
> >
> > I'm not entirely sure what a HEST or GHES is, but I think the only place
> > where I'm still not clear is if when the guest kernel is notified of
> > errors does it (a) just traverse memory by following some pointers
> > (which it may have pre-loaded at boot from UEFI), or (b) run UEFI code
> > which can call into QEMU and generate error records on demand?
> 
> So HEST is the ACPI Harware Error Source Table. It has entries in it for Generic
> HW Error Sources (GHES) amongst other types of error sources (x86 MCE etc). Each
> Error source specifies an address where the address of the CPER created by
> firmware will be populated. OS upon receipt of an error reads the CPERs to find
> the error source. It uses the addresses specified in the GHES entries of the
> HEST. This is closer to (a) above. HEST has the pointers preloaded at boot by
> UEFI.
> 
Thanks for the explanation.  Sounds to me like QEMU, through whatever
abstractions and proper methods they have to do that, must populate
memory more or less directly.

I guess this is up to whoever will actually implement support for this
to figure out.

-Christoffer

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel

csiph-web