linux-efi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: James Morse <james.morse@arm.com>
To: gengdongjiu <gengdj.1984@gmail.com>
Cc: linux-efi@vger.kernel.org, kvm@vger.kernel.org,
	matt@codeblueprint.co.uk, catalin.marinas@arm.com,
	Tyler Baicar <tbaicar@codeaurora.org>,
	will.deacon@arm.com, robert.moore@intel.com,
	paul.gortmaker@windriver.com, lv.zheng@intel.com,
	kvmarm@lists.cs.columbia.edu, Fu Wei <fu.wei@linaro.org>,
	zjzhang@codeaurora.org, linux@armlinux.org.uk,
	Xiongfeng Wang <wangxiongfeng2@huawei.com>,
	linux-acpi@vger.kernel.org, eun.taik.lee@samsung.com,
	shijie.huang@arm.com, labbott@redhat.com,
	Len Brown <lenb@kernel.org>,
	harba@codeaurora.org, John Garry <john.garry@huawei.com>,
	Marc Zyngier <marc.zyngier@arm.com>,
	Punit Agrawal <punit.agrawal@arm.com>,
	rostedt@goodmis.org, nkaje@codeaurora.org,
	Sandeepa Prabhu <sandeepa.s.prabhu@gmail.com>,
	linux-arm-kernel@lists.infradead.org, devel@acpica.org,
	rjw@rjwysocki.net, rruigrok@codeaurora.org,
	linux-kernel@vger.kernel.org, astone@redhat.com, Han
Subject: Re: [PATCH v3 3/3] arm/arm64: signal SIBGUS and inject SEA Error
Date: Fri, 12 May 2017 18:24:19 +0100	[thread overview]
Message-ID: <5915EFC3.9070507@arm.com> (raw)
In-Reply-To: <CAMj-D2A-ER8GEN32au774AY682yeMVyJwxhZoO+NkXKYYMwoQw@mail.gmail.com>

Hi gengdongjiu,

On 05/05/17 13:31, gengdongjiu wrote:
> when guest OS happen an SEA, My current solution is shown below:
> 
> (1) host EL3 firmware firstly handle the SEA error and generate the CPER record.
> (2) EL3 firmware separately copy the esr_el3, elr_el3, SPSR_el3,
> far_el3 to the esr_el2, elr_el2, SPSR_el2, far_el2.

Copying {ELR,SPSR,FAR}_EL3 to the EL2 registers rings some alarm bells: I'm sure
you exclude values from EL3 or the secure-world, we should never hand those to
the normal world.


> (3) then jump the EL2 hypervisor

> so the EL2 hypervisor uses the ESR that come from esr_el3,  here the
> ESR(esr_el3) value may be different with the exist KVM API's ESR.

The ESR may be different between EL3 and EL2. The ESR contains the severity of
the event, the CPU will choose this when it takes the SError to EL3. If it had
taken the SError to EL2, the CPU may have classified the error differently.

Firmware may need to generate a more severe ESR if it receives an error that
would be propagated by delivering SEI to a lower exception level, for example if
an EL2 system register is 'infected'.

This is the same for Qemu/kvmtool. A contained error at EL2 may be an
uncontained error if we hand it to guest EL1. Linux's RAS code will decide this
with its choice of signal to send, (and possibly which code to set).
Qemu/kvmtool need to choose an appropriate APEI notification, which may involve
generating a relevant ESR.

Also relevant is the problem we discussed earlier with trying to deliver fake
Physical-SError from software at EL3: If the SError is routed to EL2, and EL2
has PSTATE.A masked, EL3 has to wait and try again later. This is another case
where firmware may have to upgrade the classification of an error to uncontainable.


Thanks,

James

  reply	other threads:[~2017-05-12 17:24 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-04 16:52 [PATCH v3 3/3] arm/arm64: signal SIBGUS and inject SEA Error gengdongjiu
2017-05-05 12:31 ` gengdongjiu
2017-05-12 17:24   ` James Morse [this message]
2017-05-21  8:24     ` gengdongjiu
2017-05-08 17:28 ` James Morse
2017-05-08 17:54   ` Christoffer Dall
2017-05-09 14:28     ` James Morse
2017-05-10  9:15       ` gengdongjiu
2017-05-10 12:20         ` Christoffer Dall
2017-05-10 12:37           ` gengdongjiu
2017-05-10  8:44   ` gengdongjiu
2017-05-12 17:25     ` James Morse
2017-05-21  9:23       ` gengdongjiu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5915EFC3.9070507@arm.com \
    --to=james.morse@arm.com \
    --cc=astone@redhat.com \
    --cc=catalin.marinas@arm.com \
    --cc=devel@acpica.org \
    --cc=eun.taik.lee@samsung.com \
    --cc=fu.wei@linaro.org \
    --cc=gengdj.1984@gmail.com \
    --cc=harba@codeaurora.org \
    --cc=john.garry@huawei.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=labbott@redhat.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=lv.zheng@intel.com \
    --cc=marc.zyngier@arm.com \
    --cc=matt@codeblueprint.co.uk \
    --cc=nkaje@codeaurora.org \
    --cc=paul.gortmaker@windriver.com \
    --cc=punit.agrawal@arm.com \
    --cc=rjw@rjwysocki.net \
    --cc=robert.moore@intel.com \
    --cc=rostedt@goodmis.org \
    --cc=rruigrok@codeaurora.org \
    --cc=sandeepa.s.prabhu@gmail.com \
    --cc=shijie.huang@arm.com \
    --cc=tbaicar@codeaurora.org \
    --cc=wangxiongfeng2@huawei.com \
    --cc=will.deacon@arm.com \
    --cc=zjzhang@codeaurora.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).