Re: [PATCH v4 10/11] KVM: arm/arm64: Document KVM_DEV_ARM_ITS_CTRL_RESET

On Tue, Oct 17, 2017 at 09:10:08AM +0200, Eric Auger wrote: > At the moment, the in-kernel emulated ITS is not properly reset. > On guest restart/reset some registers keep their old values and > internal structures like device, ITE, and collection lists are not > freed. > > This may lead to

Re: [PATCH v4 09/11] KVM: arm/arm64: vgic-its: free caches when GITS_BASER Valid bit is cleared

On Tue, Oct 17, 2017 at 09:10:07AM +0200, Eric Auger wrote: > When the GITS_BASER.Valid gets cleared, the data structures in > guest RAM are not valid anymore. The device, collection > and LPI lists stored in the in-kernel ITS represent the same > information in some form of cache. So let's void

Re: [PATCH v4 08/11] KVM: arm/arm64: vgic-its: new helper functions to free the caches

On Tue, Oct 17, 2017 at 09:10:06AM +0200, Eric Auger wrote: > From: wanghaibin > > We create 2 new functions that frees the device and > collection lists. this is currently called by vgic_its_destroy() > and we will add other callers in subsequent patches. See my

Re: [PATCH v4 07/11] KVM: arm/arm64: vgic-its: Always attempt to save/restore device and collection tables

On Tue, Oct 17, 2017 at 09:10:05AM +0200, Eric Auger wrote: > In case the device table save fails, we currently do not > attempt to save the collection table. However it may > happen that the device table fails because the structures > in memory are inconsistent with device GITS_BASER however >

Re: [PATCH v4 06/11] KVM: arm/arm64: vgic-its: Check GITS_CBASER validity before processing commands

On Tue, Oct 17, 2017 at 09:10:04AM +0200, Eric Auger wrote: > At the moment vgic_its_process_commands() does not > check the CBASER is valid before processing any command. > Let's fix that. > > Also rename cbaser local variable into cbaser_pa to avoid > any confusion with the full register. > >

Re: [PATCH v4 04/11] KVM: arm/arm64: vgic-its: Check CBASER/BASER validity before enabling the ITS

On Tue, Oct 17, 2017 at 09:10:02AM +0200, Eric Auger wrote: > The spec says it is UNPREDICTABLE to enable the ITS > if any of the following conditions are true: > > - GITS_CBASER.Valid == 0. > - GITS_BASER.Valid == 0, for any GITS_BASER register > where the Type field indicates Device. > -

Re: [PATCH v4 03/11] KVM: arm/arm64: vgic-its: Improve error reporting on device table save

On Tue, Oct 17, 2017 at 09:10:01AM +0200, Eric Auger wrote: > At the moment the device table save() returns -EINVAL if > vgic_its_check_id() fails to return the gpa of the entry > associated to the device/collection id. Let vgic_its_check_id() > return an int instead of a bool and return a more

Re: [PATCH v4 02/11] KVM: arm/arm64: vgic-its: fix vgic_its_restore_collection_table returned value

On Tue, Oct 17, 2017 at 09:10:00AM +0200, Eric Auger wrote: > vgic_its_restore_cte returns +1 if the collection table entry > is valid and properly decoded. As a consequence, if the > collection table is fully filled with valid data that are > decoded without error,

Re: [PATCH v4 01/11] KVM: arm/arm64: vgic-its: fix return value for device table restore

On Tue, Oct 17, 2017 at 09:09:59AM +0200, Eric Auger wrote: > AT the moment if ITT only contains invalid entries, > vgic_its_restore_itt returns 1 and this is considered as > an an error in vgic_its_restore_dte. > > Also in case the device table only contains invalid entries, > the table restore

[PATCH v4 09/13] arm64: kernel: Add arch-specific SDEI entry code and CPU masking

The Software Delegated Exception Interface (SDEI) is an ARM standard for registering callbacks from the platform firmware into the OS. This is typically used to implement RAS notifications. Such notifications enter the kernel at the registered entry-point with the register values of the

[PATCH v4 10/13] firmware: arm_sdei: Add support for CPU and system power states

When a CPU enters an idle lower-power state or is powering off, we need to mask SDE events so that no events can be delivered while we are messing with the MMU as the registered entry points won't be valid. If the system reboots, we want to unregister all events and mask the CPUs. For kexec this

[PATCH v4 12/13] arm64: acpi: Remove __init from acpi_psci_use_hvc() for use by SDEI

SDEI inherits the 'use hvc' bit that is also used by PSCI. PSCI does all its initialisation early, SDEI does its late. Remove the __init annotation from acpi_psci_use_hvc(). Signed-off-by: James Morse --- The function name is unchanged as this bit is named 'PSCI_USE_HVC'

[PATCH v4 05/13] KVM: arm64: Stop save/restoring host tpidr_el1 on VHE

Now that a VHE host uses tpidr_el2 for the cpu offset we no longer need KVM to save/restore tpidr_el1. Move this from the 'common' code into the non-vhe code. While we're at it, on VHE we don't need to save the ELR or SPSR as kernel_entry in entry.S will have pushed these onto the kernel stack,

[PATCH v4 11/13] firmware: arm_sdei: add support for CPU private events

Private SDE events are per-cpu, and need to be registered and enabled on each CPU. Hide this detail from the caller by adapting our {,un}register and {en,dis}able calls to send an IPI to each CPU if the event is private. CPU private events are unregistered when the CPU is powered-off, and

[PATCH v4 00/13] arm64/firmware: Software Delegated Exception Interface

Hello! The Software Delegated Exception Interface (SDEI) is an ARM specification for registering callbacks from the platform firmware into the OS. This is intended to be used to implement firmware-first RAS notifications, but also supports vendor-defined events and binding IRQs as events. The

[PATCH v4 02/13] KVM: arm/arm64: Convert kvm_host_cpu_state to a static per-cpu allocation

kvm_host_cpu_state is a per-cpu allocation made from kvm_arch_init() used to store the host EL1 registers when KVM switches to a guest. Make it easier for ASM to generate pointers into this per-cpu memory by making it a static allocation. Signed-off-by: James Morse

[PATCH v4 08/13] arm64: Add vmap_stack header file

Today the arm64 arch code allocates an extra IRQ stack per-cpu. If we also have SDEI and VMAP stacks we need two extra per-cpu VMAP stacks. Move the VMAP stack allocation out to a helper in a new header file. This avoids missing THREADINFO_GFP, or getting the all-important alignment wrong.

[PATCH v4 13/13] firmware: arm_sdei: Discover SDEI support via ACPI

SDEI defines a new ACPI table to indicate the presence of the interface. The conduit is discovered in the same way as PSCI. For ACPI we need to create the platform device ourselves as SDEI doesn't have an entry in the DSDT. The SDEI platform device should be created after ACPI has been

[PATCH v4 07/13] firmware: arm_sdei: Add driver for Software Delegated Exceptions

The Software Delegated Exception Interface (SDEI) is an ARM standard for registering callbacks from the platform firmware into the OS. This is typically used to implement firmware notifications (such as firmware-first RAS) or promote an IRQ that has been promoted to a firmware-assisted NMI. Add

[PATCH v4 06/13] Docs: dt: add devicetree binding for describing arm64 SDEI firmware

The Software Delegated Exception Interface (SDEI) is an ARM standard for registering callbacks from the platform firmware into the OS. This is typically used to implement RAS notifications, or from an IRQ that has been promoted to a firmware-assisted NMI. Add a new devicetree binding to describe

[PATCH v4 03/13] KVM: arm64: Change hyp_panic()s dependency on tpidr_el2

Make tpidr_el2 a cpu-offset for per-cpu variables in the same way the host uses tpidr_el1. This lets tpidr_el{1,2} have the same value, and on VHE they can be the same register. KVM calls hyp_panic() when anything unexpected happens. This may occur while a guest owns the EL1 registers. KVM

[PATCH v4 04/13] arm64: alternatives: use tpidr_el2 on VHE hosts

Now that KVM uses tpidr_el2 in the same way as Linux's cpu_offset in tpidr_el1, merge the two. This saves KVM from save/restoring tpidr_el1 on VHE hosts, and allows future code to blindly access per-cpu variables without triggering world-switch. Signed-off-by: James Morse

[PATCH v4 01/13] KVM: arm64: Store vcpu on the stack during __guest_enter()

KVM uses tpidr_el2 as its private vcpu register, which makes sense for non-vhe world switch as only KVM can access this register. This means vhe Linux has to use tpidr_el1, which KVM has to save/restore as part of the host context. If the SDEI handler code runs behind KVMs back, it mustn't access

Re: [PATCH v3 04/13] arm64: alternatives: use tpidr_el2 on VHE hosts

Hi Catalin, On 16/10/17 10:58, Catalin Marinas wrote: > On Fri, Oct 13, 2017 at 05:50:45PM +0100, James Morse wrote: >> On 13/10/17 16:31, Catalin Marinas wrote: >>> On Fri, Sep 22, 2017 at 07:26:05PM +0100, James Morse wrote: diff --git a/arch/arm64/kernel/cpufeature.c

Re: [PATCH v3 10/13] firmware: arm_sdei: Add support for CPU and system power states

Hi Catalin, On 16/10/17 14:52, Catalin Marinas wrote: > On Fri, Sep 22, 2017 at 07:26:11PM +0100, James Morse wrote: >> diff --git a/include/linux/cpuhotplug.h b/include/linux/cpuhotplug.h >> index f24bfb2b9a2d..466b949474df 100644 >> --- a/include/linux/cpuhotplug.h >> +++

Re: [PATCH v3 08/13] arm64: Add vmap_stack header file

Hi Catalin, On 13/10/17 16:42, Catalin Marinas wrote: > On Fri, Sep 22, 2017 at 07:26:09PM +0100, James Morse wrote: >> diff --git a/arch/arm64/include/asm/vmap_stack.h >> b/arch/arm64/include/asm/vmap_stack.h >> new file mode 100644 >> index ..f41d043cac31 >> --- /dev/null >> +++

Re: [PATCH v3 09/13] arm64: kernel: Add arch-specific SDEI entry code and CPU masking

Hi Catalin, On 16/10/17 14:41, Catalin Marinas wrote: > On Fri, Sep 22, 2017 at 07:26:10PM +0100, James Morse wrote: >> diff --git a/arch/arm64/kernel/sdei-entry.S b/arch/arm64/kernel/sdei-entry.S >> new file mode 100644 >> index ..cf12f8da0789 >> --- /dev/null >> +++

Re: [PATCH v3 24/28] arm64/sve: KVM: Hide SVE from CPU features exposed to guests

On Tue, Oct 17, 2017 at 03:29:36PM +0100, Marc Zyngier wrote: > On 17/10/17 15:07, Dave Martin wrote: > > On Tue, Oct 17, 2017 at 06:58:16AM -0700, Christoffer Dall wrote: > >> On Tue, Oct 10, 2017 at 07:38:41PM +0100, Dave Martin wrote: > >>> KVM guests cannot currently use SVE, because SVE is

Re: [PATCH v3 02/20] arm64: Use physical counter for in-kernel reads

Hi Christoffer, On Sat, Sep 23, 2017 at 02:41:49AM +0200, Christoffer Dall wrote: > Using the physical counter allows KVM to retain the offset between the > virtual and physical counter as long as it is actively running a VCPU. > > As soon as a VCPU is released, another thread is scheduled or we

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

Hi James, > Hi gengdongjiu, > > On 14/09/17 12:12, gengdongjiu wrote: > > On 2017/9/8 0:31, James Morse wrote: > >> KVM already handles external aborts from lower exception levels, no > >> more work needs doing for TEA. > > If it is firmware first solution, that is SCR_EL3.EA=1, all SError > >

Re: [PATCH 07/10] KVM: arm/arm64: Preserve Exec permission across R/W permission faults

On 17/10/17 15:46, Christoffer Dall wrote: > On Tue, Oct 17, 2017 at 12:22:08PM +0100, Marc Zyngier wrote: >> On 16/10/17 21:08, Christoffer Dall wrote: >>> On Mon, Oct 09, 2017 at 04:20:29PM +0100, Marc Zyngier wrote: So far, we loose the Exec property whenever we take permission

Re: [PATCH 06/10] KVM: arm/arm64: Only clean the dcache on translation fault

On 17/10/17 15:36, Christoffer Dall wrote: > On Tue, Oct 17, 2017 at 10:34:15AM +0100, Marc Zyngier wrote: >> On 16/10/17 21:08, Christoffer Dall wrote: >>> On Mon, Oct 09, 2017 at 04:20:28PM +0100, Marc Zyngier wrote: The only case where we actually need to perform a dache maintenance

Re: [PATCH 10/10] arm: KVM: Use common implementation for all flushes to PoC

On Tue, Oct 17, 2017 at 01:40:00PM +0100, Marc Zyngier wrote: > On 16/10/17 21:06, Christoffer Dall wrote: > > On Mon, Oct 09, 2017 at 04:20:32PM +0100, Marc Zyngier wrote: > >> We currently have no less than three implementations for the > >> "flush to PoC" code. Let standardize on a single one.

Re: [PATCH 07/10] KVM: arm/arm64: Preserve Exec permission across R/W permission faults

On Tue, Oct 17, 2017 at 12:22:08PM +0100, Marc Zyngier wrote: > On 16/10/17 21:08, Christoffer Dall wrote: > > On Mon, Oct 09, 2017 at 04:20:29PM +0100, Marc Zyngier wrote: > >> So far, we loose the Exec property whenever we take permission > >> faults, as we always reconstruct the PTE/PMD from

Re: [PATCH 01/10] KVM: arm/arm64: Split dcache/icache flushing

On 17/10/17 15:28, Christoffer Dall wrote: > On Tue, Oct 17, 2017 at 09:57:34AM +0100, Marc Zyngier wrote: >> On 16/10/17 21:07, Christoffer Dall wrote>>> unrelated: I went and read the >> comment in __kvm_tlb_flush_vmid_ipa, and >>> I don't really understand why there is only a need to flush the

Re: [PATCH 06/10] KVM: arm/arm64: Only clean the dcache on translation fault

On Tue, Oct 17, 2017 at 10:34:15AM +0100, Marc Zyngier wrote: > On 16/10/17 21:08, Christoffer Dall wrote: > > On Mon, Oct 09, 2017 at 04:20:28PM +0100, Marc Zyngier wrote: > >> The only case where we actually need to perform a dache maintenance > >> is when we map the page for the first time, and

Re: [PATCH v3 22/28] arm64/sve: KVM: Prevent guests from using SVE

On Tue, Oct 17, 2017 at 01:50:24PM +0200, Christoffer Dall wrote: > On Tue, Oct 10, 2017 at 07:38:39PM +0100, Dave Martin wrote: > > Until KVM has full SVE support, guests must not be allowed to > > execute SVE instructions. > > > > This patch enables the necessary traps, and also ensures that

Re: [PATCH v3 24/28] arm64/sve: KVM: Hide SVE from CPU features exposed to guests

On 17/10/17 15:07, Dave Martin wrote: > On Tue, Oct 17, 2017 at 06:58:16AM -0700, Christoffer Dall wrote: >> On Tue, Oct 10, 2017 at 07:38:41PM +0100, Dave Martin wrote: >>> KVM guests cannot currently use SVE, because SVE is always >>> configured to trap to EL2. >>> >>> However, a guest that sees

Re: [PATCH 01/10] KVM: arm/arm64: Split dcache/icache flushing

On Tue, Oct 17, 2017 at 09:57:34AM +0100, Marc Zyngier wrote: > On 16/10/17 21:07, Christoffer Dall wrote: > > On Mon, Oct 09, 2017 at 04:20:23PM +0100, Marc Zyngier wrote: > >> As we're about to introduce opportunistic invalidation of the icache, > >> let's split dcache and icache flushing. > >

Re: [PATCH v3 02/28] arm64: KVM: Hide unsupported AArch64 CPU features from guests

On 17/10/17 14:51, Christoffer Dall wrote: > On Tue, Oct 10, 2017 at 07:38:19PM +0100, Dave Martin wrote: >> Currently, a guest kernel sees the true CPU feature registers >> (ID_*_EL1) when it reads them using MRS instructions. This means >> that the guest will observe features that are present

Re: [PATCH v3 24/28] arm64/sve: KVM: Hide SVE from CPU features exposed to guests

On Tue, Oct 17, 2017 at 06:58:16AM -0700, Christoffer Dall wrote: > On Tue, Oct 10, 2017 at 07:38:41PM +0100, Dave Martin wrote: > > KVM guests cannot currently use SVE, because SVE is always > > configured to trap to EL2. > > > > However, a guest that sees SVE reported as present in > >

Re: [PATCH] arm64: KVM: set right LR register value for 32 bit guest when inject abort

Hi Christoffer On 2017/10/17 3:59, Christoffer Dall wrote: > On Mon, Oct 16, 2017 at 04:10:01PM +, gengdongjiu wrote: >> Hi Marc, >> >>> >>> Please also update the 32bit code accordingly, as it looks broken too. >> >> I have updated the 32 bit code according, in my hand, there is no arm32

Re: [PATCH v3 23/28] arm64/sve: KVM: Treat guest SVE use as undefined instruction execution

On Tue, Oct 10, 2017 at 07:38:40PM +0100, Dave Martin wrote: > When trapping forbidden attempts by a guest to use SVE, we want the > guest to see a trap consistent with SVE not being implemented. > > This patch injects an undefined instruction exception into the > guest in response to such an

[PATCH RESEND v2] arm/arm64: KVM: set right LR register value for 32 bit guest when inject abort

When a exception is trapped to EL2, hardware uses ELR_ELx to hold the current fault instruction address. If KVM wants to inject a abort to 32 bit guest, it needs to set the LR register for the guest to emulate this abort happened in the guest. Because ARM32 architecture is pipelined execution, so

Re: [PATCH v3 24/28] arm64/sve: KVM: Hide SVE from CPU features exposed to guests

On Tue, Oct 10, 2017 at 07:38:41PM +0100, Dave Martin wrote: > KVM guests cannot currently use SVE, because SVE is always > configured to trap to EL2. > > However, a guest that sees SVE reported as present in > ID_AA64PFR0_EL1 may legitimately expect that SVE works and try to > use it. Instead

Re: [PATCH v3 02/28] arm64: KVM: Hide unsupported AArch64 CPU features from guests

On Tue, Oct 10, 2017 at 07:38:19PM +0100, Dave Martin wrote: > Currently, a guest kernel sees the true CPU feature registers > (ID_*_EL1) when it reads them using MRS instructions. This means > that the guest will observe features that are present in the > hardware but the host doesn't understand

[PATCH v7 1/4] 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

[PATCH v7 4/4] arm64: kvm: handle SEI notification for guest

when KVM received SError, it firstly classified the error according to [ESR_ELx.AET]. If the SEI is Uncategorized or IMPLEMENTATION DEFINED directly inject virtual SError with IMPLEMENTATION DEFINED syndrome. If the SError error is not propagated, then let host to handle it. Because usually the

[PATCH v7 2/4] arm64: kvm: Introduce KVM_ARM_SET_SERROR_ESR ioctl

On ARM64 SError syndrome value is specific to the model being emulated for the guest and user space needs a way to tell the kernel this value. userspace can specify different value to affect guest OS error recovery behaviour. We make this API ARM-specific as we haven't yet reached a consensus for

[PATCH v7 3/4] arm64: kvm: Set Virtual SError Exception Syndrome for guest

RAS Extension add a VSESR_EL2 register which can provides the syndrome value reported to software on taking a virtual SError interrupt exception. This patch supports to specify this Syndrome. In the RAS Extensions we can not set all-zero syndrome value for SError, which means 'RAS error:

Re: [PATCH 10/10] arm: KVM: Use common implementation for all flushes to PoC

On 16/10/17 21:06, Christoffer Dall wrote: > On Mon, Oct 09, 2017 at 04:20:32PM +0100, Marc Zyngier wrote: >> We currently have no less than three implementations for the >> "flush to PoC" code. Let standardize on a single one. This >> requires a bit of unpleasant moving around, and relies on >>

Re: [PATCH v3 22/28] arm64/sve: KVM: Prevent guests from using SVE

On Tue, Oct 10, 2017 at 07:38:39PM +0100, Dave Martin wrote: > Until KVM has full SVE support, guests must not be allowed to > execute SVE instructions. > > This patch enables the necessary traps, and also ensures that the > traps are disabled again on exit from the guest so that the host > can

Re: [PATCH 07/10] KVM: arm/arm64: Preserve Exec permission across R/W permission faults

On 16/10/17 21:08, Christoffer Dall wrote: > On Mon, Oct 09, 2017 at 04:20:29PM +0100, Marc Zyngier wrote: >> So far, we loose the Exec property whenever we take permission >> faults, as we always reconstruct the PTE/PMD from scratch. This >> can be counter productive as we can end-up with the

Re: [PATCH 06/10] KVM: arm/arm64: Only clean the dcache on translation fault

On 16/10/17 21:08, Christoffer Dall wrote: > On Mon, Oct 09, 2017 at 04:20:28PM +0100, Marc Zyngier wrote: >> The only case where we actually need to perform a dache maintenance >> is when we map the page for the first time, and subsequent permission >> faults do not require cache maintenance.

[PATCH v4 07/11] KVM: arm/arm64: vgic-its: Always attempt to save/restore device and collection tables

In case the device table save fails, we currently do not attempt to save the collection table. However it may happen that the device table fails because the structures in memory are inconsistent with device GITS_BASER however this does not mean collection backup can't and shouldn't be performed.

[PATCH v4 11/11] KVM: arm/arm64: vgic-its: Implement KVM_DEV_ARM_ITS_CTRL_RESET

On reset we clear the valid bits of GITS_CBASER and GITS_BASER. We also clear command queue registers and free the cache (device, collection, and lpi lists). Signed-off-by: Eric Auger Reviewed-by: Christoffer Dall --- v2 -> v3: - added

[PATCH v4 09/11] KVM: arm/arm64: vgic-its: free caches when GITS_BASER Valid bit is cleared

When the GITS_BASER.Valid gets cleared, the data structures in guest RAM are not valid anymore. The device, collection and LPI lists stored in the in-kernel ITS represent the same information in some form of cache. So let's void the cache. Signed-off-by: Eric Auger ---

[PATCH v4 10/11] KVM: arm/arm64: Document KVM_DEV_ARM_ITS_CTRL_RESET

At the moment, the in-kernel emulated ITS is not properly reset. On guest restart/reset some registers keep their old values and internal structures like device, ITE, and collection lists are not freed. This may lead to various bugs. Among them, we can have incorrect state backup or failure when

[PATCH v4 08/11] KVM: arm/arm64: vgic-its: new helper functions to free the caches

From: wanghaibin We create 2 new functions that frees the device and collection lists. this is currently called by vgic_its_destroy() and we will add other callers in subsequent patches. We also remove the check on its->device_list.next as it looks unnecessary.

[PATCH v4 06/11] KVM: arm/arm64: vgic-its: Check GITS_CBASER validity before processing commands

At the moment vgic_its_process_commands() does not check the CBASER is valid before processing any command. Let's fix that. Also rename cbaser local variable into cbaser_pa to avoid any confusion with the full register. Signed-off-by: Eric Auger ---

[PATCH v4 03/11] KVM: arm/arm64: vgic-its: Improve error reporting on device table save

At the moment the device table save() returns -EINVAL if vgic_its_check_id() fails to return the gpa of the entry associated to the device/collection id. Let vgic_its_check_id() return an int instead of a bool and return a more precised error value: - EINVAL in case the id is out of range - EFAULT

[PATCH v4 02/11] KVM: arm/arm64: vgic-its: fix vgic_its_restore_collection_table returned value

vgic_its_restore_cte returns +1 if the collection table entry is valid and properly decoded. As a consequence, if the collection table is fully filled with valid data that are decoded without error, vgic_its_restore_collection_table() returns +1. This is wrong. Let's use the standard C

[PATCH v4 04/11] KVM: arm/arm64: vgic-its: Check CBASER/BASER validity before enabling the ITS

The spec says it is UNPREDICTABLE to enable the ITS if any of the following conditions are true: - GITS_CBASER.Valid == 0. - GITS_BASER.Valid == 0, for any GITS_BASER register where the Type field indicates Device. - GITS_BASER.Valid == 0, for any GITS_BASER register where the Type field

[PATCH v4 05/11] KVM: arm/arm64: vgic-its: Check GITS_BASER Valid bit before saving tables

At the moment we don't properly check the GITS_BASER.Valid bit before saving the collection and device tables. On vgic_its_save_collection_table() we use the GITS_BASER gpa field whereas the Valid bit should be used. On vgic_its_save_device_tables() there is no check. This can cause various

[PATCH v4 01/11] KVM: arm/arm64: vgic-its: fix return value for device table restore

AT the moment if ITT only contains invalid entries, vgic_its_restore_itt returns 1 and this is considered as an an error in vgic_its_restore_dte. Also in case the device table only contains invalid entries, the table restore fails and this is not correct. This patch fully revisits the errror

[PATCH v4 00/11] vITS Migration fixes and reset

This series fixes various bugs observed when saving/restoring the ITS state before the guest writes the ITS registers (on first boot or after reset/reboot). This is a follow up of Wanghaibin's series [1] plus additional patches following additional code review. It also proposes one ITS reset

Re: [PATCH 01/10] KVM: arm/arm64: Split dcache/icache flushing

On Mon, Oct 16, 2017 at 02:35:47PM -0700, Roy Franz (Cavium) wrote: > On Mon, Oct 9, 2017 at 8:20 AM, Marc Zyngier wrote: > > As we're about to introduce opportunistic invalidation of the icache, > > let's split dcache and icache flushing. > > > > Signed-off-by: Marc Zyngier