Re: [PATCH v9 5/7] arm64: kvm: Introduce KVM_ARM_SET_SERROR_ESR ioctl

2018-03-07 Thread gengdongjiu
Hi James, sorry for my late response due to chines new year. 2018-02-16 1:55 GMT+08:00 James Morse : > Hi gengdongjiu, > > On 12/02/18 10:19, gengdongjiu wrote: >> On 2018/2/10 1:44, James Morse wrote: >>> The point? We can't know what a CPU without the RAS extensions puts in >>> there. >>> >>

Re: [PATCH 1/2] KVM: arm/arm64: vgic: Don't populate multiple LRs with the same vintid

2018-03-07 Thread Christoffer Dall
On Wed, Mar 7, 2018 at 12:40 PM, Marc Zyngier wrote: > The vgic code is trying to be clever when injecting GICv2 SGIs, > and will happily populate LRs with the same interrupt number if > they come from multiple vcpus (after all, they are distinct > interrupt sources). > > Unfortunately, this is ag

Re: [PATCH 02/11] ACPI / APEI: Generalise the estatus queue's add/remove and notify code

2018-03-07 Thread James Morse
Hi Borislav, Punit, On 01/03/18 22:35, Borislav Petkov wrote: > On Thu, Mar 01, 2018 at 06:06:59PM +, Punit Agrawal wrote: >> The 64-bit support lives in arch/arm64 and the die() there doesn't >> contain an oops_begin()/oops_end(). But the lack of oops_begin() on >> arm64 doesn't really matter

Re: [PATCH v5 12/23] arm64: insn: Allow ADD/SUB (immediate) with LSL #12

2018-03-07 Thread Catalin Marinas
On Thu, Mar 01, 2018 at 03:55:27PM +, Marc Zyngier wrote: > The encoder for ADD/SUB (immediate) can only cope with 12bit > immediates, while there is an encoding for a 12bit immediate shifted > by 12 bits to the left. > > Let's fix this small oversight by allowing the LSL_12 bit to be set. >

Re: [PATCH v5 11/23] arm64; insn: Add encoder for the EXTR instruction

2018-03-07 Thread Catalin Marinas
On Thu, Mar 01, 2018 at 03:55:26PM +, Marc Zyngier wrote: > Add an encoder for the EXTR instruction, which also implements the ROR > variant (where Rn == Rm). > > Reviewed-by: Christoffer Dall > Signed-off-by: Marc Zyngier Acked-by: Catalin Marinas _

Re: [PATCH v5 05/23] arm64: cpufeatures: Drop the ARM64_HYP_OFFSET_LOW feature flag

2018-03-07 Thread Catalin Marinas
On Thu, Mar 01, 2018 at 03:55:20PM +, Marc Zyngier wrote: > Now that we can dynamically compute the kernek/hyp VA mask, there > is no need for a feature flag to trigger the alternative patching. > Let's drop the flag and everything that depends on it. > > Acked-by: Christoffer Dall > Signed-o

Re: [PATCH v5 04/23] arm64: KVM: Dynamically patch the kernel/hyp VA mask

2018-03-07 Thread Catalin Marinas
On Thu, Mar 01, 2018 at 03:55:19PM +, Marc Zyngier wrote: > So far, we're using a complicated sequence of alternatives to > patch the kernel/hyp VA mask on non-VHE, and NOP out the > masking altogether when on VHE. > > The newly introduced dynamic patching gives us the opportunity > to simplif

Re: [PATCH v5 02/23] arm64: insn: Add N immediate encoding

2018-03-07 Thread Catalin Marinas
On Thu, Mar 01, 2018 at 03:55:17PM +, Marc Zyngier wrote: > We're missing the a way to generate the encoding of the N immediate, > which is only a single bit used in a number of instruction that take > an immediate. > > Acked-by: Christoffer Dall > Signed-off-by: Marc Zyngier Acked-by: Cata

Re: [PATCH v5 03/23] arm64: insn: Add encoder for bitwise operations using literals

2018-03-07 Thread Catalin Marinas
On Thu, Mar 01, 2018 at 03:55:18PM +, Marc Zyngier wrote: > We lack a way to encode operations such as AND, ORR, EOR that take > an immediate value. Doing so is quite involved, and is all about > reverse engineering the decoding algorithm described in the > pseudocode function DecodeBitMasks().

Re: [PATCH v5 01/23] arm64: alternatives: Add dynamic patching feature

2018-03-07 Thread Catalin Marinas
On Thu, Mar 01, 2018 at 03:55:16PM +, Marc Zyngier wrote: > We've so far relied on a patching infrastructure that only gave us > a single alternative, without any way to provide a range of potential > replacement instructions. For a single feature, this is an all or > nothing thing. > > It wou

Re: [PATCH 2/2] kvm: arm/arm64: vgic-v3: Tighten synchronization for guests using v2 on v3

2018-03-07 Thread Andre Przywara
Hi, On 07/03/18 12:40, Marc Zyngier wrote: > On guest exit, and when using GICv2 on GICv3, we use a dsb(st) to > force synchronization between the memory-mapped guest view and > the system-register view that the hypervisor uses. > > This is incorrect, as the spec calls out the need for "a DSB who

[PATCH v7] arm64: Add support for new control bits CTR_EL0.DIC and CTR_EL0.IDC

2018-03-07 Thread Shanker Donthineni
The DCache clean & ICache invalidation requirements for instructions to be data coherence are discoverable through new fields in CTR_EL0. The following two control bits DIC and IDC were defined for this purpose. No need to perform point of unification cache maintenance operations from software on s

Re: [PATCH 1/2] KVM: arm/arm64: vgic: Don't populate multiple LRs with the same vintid

2018-03-07 Thread Andre Przywara
Hi, On 07/03/18 12:40, Marc Zyngier wrote: > The vgic code is trying to be clever when injecting GICv2 SGIs, > and will happily populate LRs with the same interrupt number if > they come from multiple vcpus (after all, they are distinct > interrupt sources). > > Unfortunately, this is against the

Re: [PATCH] KVM: arm/arm64: VGIC MMIO: add missing irq_lock

2018-03-07 Thread Marc Zyngier
On 06/03/18 09:21, Andre Przywara wrote: > Our irq_is_pending() helper function accesses multiple members of the > vgic_irq struct, so we need to hold the lock when calling it. > Add that requirement as a comment to the definition and take the lock > around the call in vgic_mmio_read_pending(), whe

Re: [PATCH] KVM: arm/arm64: Reset mapped IRQs on VM reset

2018-03-07 Thread Marc Zyngier
On 05/03/18 10:36, Christoffer Dall wrote: > We currently don't allow resetting mapped IRQs from userspace, because > their state is controlled by the hardware. But we do need to reset the > state when the VM is reset, so we provide a function for the 'owner' of > the mapped interrupt to reset the

Re: [PATCH v5 01/40] KVM: arm/arm64: Avoid vcpu_load for other vcpu ioctls than KVM_RUN

2018-03-07 Thread Marc Zyngier
On 27/02/18 11:33, Christoffer Dall wrote: > From: Christoffer Dall > > Calling vcpu_load() registers preempt notifiers for this vcpu and calls > kvm_arch_vcpu_load(). The latter will soon be doing a lot of heavy > lifting on arm/arm64 and will try to do things such as enabling the > virtual tim

Re: [Qemu-devel] [Qemu-arm] VCPU hotplug on KVM/ARM

2018-03-07 Thread Marc Zyngier
On 01/03/18 13:32, David Hildenbrand wrote: > On 01.03.2018 11:05, Peter Maydell wrote: >> On 1 March 2018 at 09:50, Igor Mammedov wrote: >>> In QEMU on x86 (and I think ppc, s390 as well), we create vCPUs on demand.>> >>> It would be nice if ARM would be able to do that too, >>> so that it could

[PATCH 2/2] kvm: arm/arm64: vgic-v3: Tighten synchronization for guests using v2 on v3

2018-03-07 Thread Marc Zyngier
On guest exit, and when using GICv2 on GICv3, we use a dsb(st) to force synchronization between the memory-mapped guest view and the system-register view that the hypervisor uses. This is incorrect, as the spec calls out the need for "a DSB whose required access type is both loads and stores with

[PATCH 1/2] KVM: arm/arm64: vgic: Don't populate multiple LRs with the same vintid

2018-03-07 Thread Marc Zyngier
The vgic code is trying to be clever when injecting GICv2 SGIs, and will happily populate LRs with the same interrupt number if they come from multiple vcpus (after all, they are distinct interrupt sources). Unfortunately, this is against the letter of the architecture, and the GICv2 architecture

[PATCH 0/2] KVM: arm/arm64: GICv2-on-v3 fixes

2018-03-07 Thread Marc Zyngier
I've been trying to run VMs on a GICv3-based system that offers the GICv2 compatibility feature, and noticed that they would tend to slowly die under load. It turned out that this is due to KVM not being exactly true to the architecture, and ends up injecting multiple SGI with the same vintid, whi

Re: [PATCH v6] arm64: Add support for new control bits CTR_EL0.DIC and CTR_EL0.IDC

2018-03-07 Thread Will Deacon
On Tue, Mar 06, 2018 at 01:33:00PM -0600, Shanker Donthineni wrote: > > I also confirmed with Thomas Speier, we can skip __flush_icache_all() if > > DIC=1. Thanks, > Planning to patch __flush_icache_all() itself instead of changing the > callers. This > way we can avoid "ic ialluis" completely.