[PATCH v6 7/7] arm64: kvm: handle SEI notification and pass the virtual syndrome

After received SError, KVM firstly classified the error. Not call memory_failure() to handle it. Because the address recorded by APEI is not accurated, so can not identify the address to hwpoison memory. If the SError error come from guest user mode and is not propagated, then signal user space

[PATCH v6 2/7] KVM: arm64: Save ESR_EL2 on guest SError

From: James Morse When we exit a guest due to an SError the vcpu fault info isn't updated with the ESR. Today this is only done for traps. The v8.2 RAS Extensions define ISS values for SError. Update the vcpu's fault_info with the ESR on SError so that handle_exit() can

[PATCH v6 0/7] Add RAS virtualization support for SEA/SEI notification type in KVM

In the firmware-first RAS solution, corrupt data is detected in a memory location when guest OS application software executing at EL0 or guest OS kernel El1 software are reading from the memory. The memory node records errors in an error record accessible using system registers. Because

[PATCH v6 3/7] acpi: apei: remove the unused code

In current code logic, the two functions ghes_sea_add() and ghes_sea_remove() are only called when CONFIG_ACPI_APEI_SEA is defined. If not, it will return errors in the ghes_probe() and not contiue. Hence, remove the unnecessary handling when CONFIG_ACPI_APEI_SEI is not defined. change since v5:

[PATCH v6 6/7] KVM: arm64: allow get exception information from userspace

when userspace gets SIGBUS signal, it does not know whether this is a synchronous external abort or SError, so needs to get the exception syndrome. This patch allows userspace can get this values. For syndrome, only give userspace syndrome EC and ISS. Now we move the synchronous external abort

[PATCH v6 1/7] arm64: cpufeature: Detect CPU RAS Extentions

From: Xie XiuQi ARM's v8.2 Extentions add support for Reliability, Availability and Serviceability (RAS). On CPUs with these extensions system software can use additional barriers to isolate errors and determine if faults are pending. Add cpufeature detection and a barrier

[PATCH v6 5/7] arm64: kvm: route synchronous external abort exceptions to el2

ARMv8.2 adds a new bit HCR_EL2.TEA which controls to route synchronous external aborts to EL2, and adds a trap control bit HCR_EL2.TERR which controls to trap all Non-secure EL1&0 error record accesses to EL2. This patch enables the two bits for the guest OS. when an synchronous abort is

Re: [PATCH v3 57/59] KVM: arm/arm64: GICv4: Theory of operations

On Mon, Jul 31, 2017 at 06:26:35PM +0100, Marc Zyngier wrote: > Yet another braindump so I can free some cells... > > Signed-off-by: Marc Zyngier > --- > virt/kvm/arm/vgic/vgic-v4.c | 68 > + > 1 file changed, 68 insertions(+) >

Re: [PATCH v3 50/59] KVM: arm/arm64: GICv4: Use pending_last as a scheduling hint

On Mon, Jul 31, 2017 at 06:26:28PM +0100, Marc Zyngier wrote: > When a vPE exits, the pending_last flag is set when there are > pending VLPIs stored in the pending table. Similarily, we set > this flag when a doorbell interrupt fires, as it indicates the > same condition. > > Let's update

Re: [PATCH v3 48/59] KVM: arm/arm64: GICv4: Handle INVALL applied to a vPE

On Mon, Jul 31, 2017 at 06:26:26PM +0100, Marc Zyngier wrote: > Since when updating the properties one LPI at a time, there is no > need to perform an INV each time we read one. Instead, we rely > on the final VINVALL that gets sent to the ITS to do the work. > > Signed-off-by: Marc Zyngier

Re: [PATCH v3 49/59] KVM: arm/arm64: GICv4: Propagate VLPI properties at map time

On Mon, Jul 31, 2017 at 06:26:27PM +0100, Marc Zyngier wrote: > When the VLPI gets mapped, it must inherit the configuration of > LPI configured at the vITS level. FOr that purpose, let's make *the LPI *For that > update_lpi_config globally available and call it just after > having performed the

Re: [PATCH v3 44/59] KVM: arm/arm64: GICv4: Handle MOVI applied to a VLPI

On Mon, Jul 31, 2017 at 06:26:22PM +0100, Marc Zyngier wrote: > When the guest issues a MOVI, we need to tell the physical ITS > that we're now targetting a new vcpu. This is done by extracting > the current mapping, updating the target, and reapplying the > mapping. The core ITS code should do

Re: [PATCH v3 47/59] KVM: arm/arm64: GICv4: Propagate property updates to VLPIs

On Mon, Jul 31, 2017 at 06:26:25PM +0100, Marc Zyngier wrote: > Upon updating a property, we propagate it all the way to the physical > ITS, and ask for an INV command to be executed there. > > Signed-off-by: Marc Zyngier Acked-by: Christoffer Dall >

Re: [PATCH v3 45/59] KVM: arm/arm64: GICv4: Handle CLEAR applied to a VLPI

On Mon, Jul 31, 2017 at 06:26:23PM +0100, Marc Zyngier wrote: > Handling CLEAR is pretty easy. Just ask the ITS driver to clear > the corresponding pending bit (which will turn into a CLEAR > command on the physical side). > > Signed-off-by: Marc Zyngier Acked-by:

Re: [PATCH v3 51/59] KVM: arm/arm64: GICv4: Add doorbell interrupt handling

On Fri, Aug 04, 2017 at 08:44:04AM +0100, Marc Zyngier wrote: > On 31/07/17 18:26, Marc Zyngier wrote: > > When a vPE is not running, a VLPI being made pending results in a > > doorbell interrupt being delivered. Let's handle this interrupt > > and update the pending_last flag that indicates that

Re: [PATCH v3 54/59] KVM: arm/arm64: GICv4: Enable virtual cpuif if VLPIs can be delivered

On Mon, Jul 31, 2017 at 06:26:32PM +0100, Marc Zyngier wrote: > In order for VLPIs to be delivered to the guest, we must make > sure that the cpuif is always enabled, irrespective of the > presence of virtual interrupt in the LRs. > > Signed-off-by: Marc Zyngier > --- >

Re: [PATCH v3 56/59] KVM: arm/arm64: GICv4: Prevent heterogenous systems from using GICv4

On Mon, Jul 31, 2017 at 06:26:34PM +0100, Marc Zyngier wrote: > The GICv4 architecture doesn't prevent CPUs implementing GICv4 to > cohabit with CPUs limited to GICv3 in the same system. > > This is mad (the sheduler would have to be made aware of the v4 *scheduler > capability), and we're

Re: [PATCH v3 52/59] KVM: arm/arm64: GICv4: Use the doorbell interrupt as an unblocking source

On Mon, Jul 31, 2017 at 06:26:30PM +0100, Marc Zyngier wrote: > The doorbell interrupt is only useful if the vcpu is blocked on WFI. > In all other cases, recieving a doorbell interrupt is just a waste > of cycles. > > So let's only enable the doorbell if a vcpu is getting blocked, > and disable

Re: [PATCH v3 51/59] KVM: arm/arm64: GICv4: Add doorbell interrupt handling

On Mon, Jul 31, 2017 at 06:26:29PM +0100, Marc Zyngier wrote: > When a vPE is not running, a VLPI being made pending results in a > doorbell interrupt being delivered. Let's handle this interrupt > and update the pending_last flag that indicates that VLPIs are > pending. The corresponding vcpu is

Re: [PATCH v3 55/59] KVM: arm/arm64: GICv4: Enable VLPI support

On Mon, Jul 31, 2017 at 06:26:33PM +0100, Marc Zyngier wrote: > All it takes is the has_v4 flag to be set in gic_kvm_info > as well as "kvm-arm.vgic_v4_enable=1" being passed on the > command line for GICv4 to be enabled in KVM. > > Signed-off-by: Marc Zyngier So I'm

Re: [PATCH v3 53/59] KVM: arm/arm64: GICv4: Hook vPE scheduling into vgic flush/sync

On Mon, Jul 31, 2017 at 06:26:31PM +0100, Marc Zyngier wrote: > The redistributor needs to be told which vPE is about to be run, > and tells us whether there is any pending VLPI on exit. > > Let's add the scheduling calls to the vgic flush/sync functions, > allowing the VLPIs to be delivered to

Re: [PATCH v3 42/59] KVM: arm/arm64: GICv4: Handle INT command applied to a VLPI

On Mon, Jul 31, 2017 at 06:26:20PM +0100, Marc Zyngier wrote: > If the guest issues an INT command targetting a VLPI, let's > call into the irq_set_irqchip_state() helper to make it pending > on the physical side. > > This works just as well if userspace decides to inject an interrupt > using the

Re: [PATCH v3 43/59] KVM: arm/arm64: GICv4: Unmap VLPI when freeing an LPI

On Mon, Jul 31, 2017 at 06:26:21PM +0100, Marc Zyngier wrote: > When freeing an LPI (on a DISCARD command, for example), we need > to unmap the VLPI down to the physical ITS level. > > Signed-off-by: Marc Zyngier > --- > virt/kvm/arm/vgic/vgic-its.c | 6 +- > 1 file