Hi,
On 2017/3/22 6:47, Tyler Baicar wrote:
> + fault_ipa = kvm_vcpu_get_fault_ipa(vcpu);
> +
> + /* The host kernel will handle the synchronous external abort. There
> + * is no need to pass the error into the guest.
> + */
> + if (is_abort_synchronous(fault_status))
> +
Hi Tyler,
On 21/03/17 22:47, Tyler Baicar wrote:
> Currently external aborts are unsupported by the guest abort
> handling. Add handling for SEAs so that the host kernel reports
> SEAs which occur in the guest kernel.
Looks good,
Can we squash the APEI changes into the patch that added them?
Hi ,
Qemu master or v2.9.0-rc1 doesn't launch guest when host kernel
version 4.10 or lower on Aarch64 (cavium ThunderX), its failing with
abort "qemu-system-aarch64: KVM_GET_DEVICE_ATTR failed: No such
device or address"
"GICv3 live migration support" patch breaks the compatibility b/w
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 +, James Morse wrote:
>> On 21/03/17 11:34, Christoffer Dall wrote:
>>> On Tue, Mar 21, 2017 at 02:32:29PM +0800,
On Mon, Mar 27, 2017 at 05:03:41PM +0100, Marc Zyngier wrote:
> PMSWINC_EL0 is a WO register, so let's UNDEF when reading from it
> (in the highly hypothetical case where this doesn't UNDEF at EL1).
>
> Signed-off-by: Marc Zyngier
Reviewed-by: Christoffer Dall
On Mon, Mar 27, 2017 at 05:03:37PM +0100, Marc Zyngier wrote:
> There is a lot of duplication in the pmu_*_el0_disabled helpers,
> and as we're going to modify them shortly, let's move all the
> common stuff in a single function.
>
> No functionnal change.
>
> Signed-off-by: Marc Zyngier
Hi Peter,
On 28/03/17 12:33, Peter Maydell wrote:
> On 28 March 2017 at 12:23, Christoffer Dall wrote:
>> On Tue, Mar 28, 2017 at 11:48:08AM +0100, James Morse wrote:
>>> On the host, part of UEFI is involved to generate the CPER records.
>>> In a guest?, I don't know.
>>> Qemu
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
Hi gengdongjiu,
On 28/03/17 13:16, gengdongjiu wrote:
> On 2017/3/28 19:54, 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:
On the host, part of UEFI is involved to generate the CPER
On 28/03/17 13:46, Christoffer Dall wrote:
> On Mon, Mar 27, 2017 at 05:03:37PM +0100, Marc Zyngier wrote:
>> There is a lot of duplication in the pmu_*_el0_disabled helpers,
>> and as we're going to modify them shortly, let's move all the
>> common stuff in a single function.
>>
>> No functionnal
On Mon, Mar 27, 2017 at 05:03:36PM +0100, Marc Zyngier wrote:
> Running the following code:
>
> root@zomby-woof:~# cat test-pmu.c
> int main(int argc, char *argv[])
> {
> unsigned int val;
> asm ("mrc p15, 0, %0, c9, c13, 0\n" : "=r" (val));
> return val;
> }
>
> in a 32bit
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
On 28/03/17 13:46, Christoffer Dall wrote:
> On Mon, Mar 27, 2017 at 05:03:43PM +0100, Marc Zyngier wrote:
>> If we fail to emulate a mrrc instruction, we:
>> 1) deliver an exception,
>> 2) spit a nastygram on the console,
>> 3) write back some garbage to Rt/Rt2
>>
>> While 1) and 2) are perfectly
On Mon, Mar 27, 2017 at 05:03:44PM +0100, Marc Zyngier wrote:
> Reads from write-only system registers are generally confined to
> EL1 and not propagated to EL2 (that's what the architecture
> mantates). In order to be sure that we have a sane behaviour
> even in the unlikely event that we have a
On Mon, Mar 27, 2017 at 05:03:42PM +0100, Marc Zyngier wrote:
> Instead of considering that a sysreg accessor has failed when
> returning false, let's consider that it is *always* successful
> (after all, we won't stand for an incomplete emulation).
That's right!
>
> The return value now simply
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,
> > > >
Christoffer Dall writes:
> On Mon, Mar 27, 2017 at 02:31:44PM +0100, Punit Agrawal wrote:
>> Christoffer Dall writes:
>>
>> > On Mon, Mar 27, 2017 at 01:00:56PM +0100, James Morse wrote:
>> >> Hi guys,
>> >>
>> >> On 27/03/17 12:20, Punit Agrawal wrote:
>>
On Tue, Mar 28, 2017 at 03:50:51PM +0100, Punit Agrawal wrote:
> Christoffer Dall writes:
>
> > On Mon, Mar 27, 2017 at 02:31:44PM +0100, Punit Agrawal wrote:
> >> Christoffer Dall writes:
> >>
> >> > On Mon, Mar 27, 2017 at 01:00:56PM +0100, James Morse
Hello Marc,
On 3/24/2017 8:03 AM, Marc Zyngier wrote:
On 21/03/17 22:47, Tyler Baicar wrote:
Currently external aborts are unsupported by the guest abort
handling. Add handling for SEAs so that the host kernel reports
SEAs which occur in the guest kernel.
Signed-off-by: Tyler Baicar
Hello Christoffer,
On 3/24/2017 10:01 AM, Christoffer Dall wrote:
On Tue, Mar 21, 2017 at 04:47:05PM -0600, Tyler Baicar wrote:
Currently external aborts are unsupported by the guest abort
handling. Add handling for SEAs so that the host kernel reports
SEAs which occur in the guest kernel.
Hello,
On 3/28/2017 3:53 AM, gengdongjiu wrote:
Hi,
On 2017/3/22 6:47, Tyler Baicar wrote:
+ fault_ipa = kvm_vcpu_get_fault_ipa(vcpu);
+
+ /* The host kernel will handle the synchronous external abort. There
+* is no need to pass the error into the guest.
+*/
+
Hello,
On 3/27/2017 10:19 PM, gengdongjiu wrote:
Hi Tyler,
I have a question for below code.
On 2017/3/25 0:01, Christoffer Dall wrote:
is_iabt = kvm_vcpu_trap_is_iabt(vcpu);
- if (unlikely(!is_iabt && kvm_vcpu_dabt_isextabt(vcpu))) {
+ if (unlikely(!is_iabt &&
Hello Christoffer,
On 3/28/2017 2:26 PM, Christoffer Dall wrote:
On Tue, Mar 28, 2017 at 01:30:40PM -0600, Tyler Baicar wrote:
Currently external aborts are unsupported by the guest abort
handling. Add handling for SEAs so that the host kernel reports
SEAs which occur in the guest kernel.
On Tue, Mar 28, 2017 at 03:33:17PM -0600, Baicar, Tyler wrote:
> Hello Christoffer,
>
>
> On 3/28/2017 2:26 PM, Christoffer Dall wrote:
> >On Tue, Mar 28, 2017 at 01:30:40PM -0600, Tyler Baicar wrote:
> >>Currently external aborts are unsupported by the guest abort
> >>handling. Add handling for
On Wed, Mar 22, 2017 at 06:35:13PM +, Mark Rutland wrote:
> On Fri, Mar 10, 2017 at 06:35:55PM +, Will Deacon wrote:
> > On Fri, Mar 10, 2017 at 08:17:22AM +, Marc Zyngier wrote:
>
> > > The next question is how do we merge this. Obviously, we can't split it
> > > between trees, and
UEFI spec allows for non-standard section in Common Platform Error
Record. This is defined in section N.2.3 of UEFI version 2.5.
Currently if the CPER section's type (UUID) does not match with
one of the section types that the kernel knows how to parse, the
section is skipped. Therefore, user is
UEFI spec allows for non-standard section in Common Platform Error
Record. This is defined in section N.2.3 of UEFI version 2.5.
Currently if the CPER section's type (UUID) does not match with
any section type that the kernel knows how to parse, trace event
is not generated for such section. And
Currently there are trace events for the various RAS
errors with the exception of ARM processor type errors.
Add a new trace event for such errors so that the user
will know when they occur. These trace events are
consistent with the ARM processor error section type
defined in UEFI 2.6 spec
A RAS (Reliability, Availability, Serviceability) controller
may be a separate processor running in parallel with OS
execution, and may generate error records for consumption by
the OS. If the RAS controller produces multiple error records,
then they may be overwritten before the OS has consumed
SEA exceptions are often caused by an uncorrected hardware
error, and are handled when data abort and instruction abort
exception classes have specific values for their Fault Status
Code.
When SEA occurs, before killing the process, report the error
in the kernel logs.
Update fault_info[] with
When a memory error, CPU error, PCIe error, or other type of hardware error
that's covered by RAS occurs, firmware should populate the shared GHES memory
location with the proper GHES structures to notify the OS of the error.
For example, platforms that implement firmware first handling may
On Tue, Mar 28, 2017 at 1:16 PM, Christoffer Dall wrote:
> Hi Radha,
>
> On Tue, Mar 28, 2017 at 12:58:24PM -0700, Radha Mohan wrote:
>> Hi,
>> I am seeing an issue with qemu-system-aarch64 when using pflash
>> (booting kernel via UEFI bios).
>>
>> Host kernel:
On Tue, Mar 28, 2017 at 01:30:40PM -0600, Tyler Baicar wrote:
> Currently external aborts are unsupported by the guest abort
> handling. Add handling for SEAs so that the host kernel reports
> SEAs which occur in the guest kernel.
>
> When an SEA occurs in the guest kernel, the guest exits and is
On Tue, Mar 28, 2017 at 07:48:28PM +0100, Mark Rutland wrote:
> On Wed, Mar 22, 2017 at 06:35:13PM +, Mark Rutland wrote:
> > On Fri, Mar 10, 2017 at 06:35:55PM +, Will Deacon wrote:
> > > On Fri, Mar 10, 2017 at 08:17:22AM +, Marc Zyngier wrote:
> >
> > > > The next question is how
34 matches
Mail list logo