linux-stable.git/virt, branch v4.12.7

KVM: arm/arm64: Handle hva aging while destroying the vm

2017-08-11T15:33:52+00:00

commit 7e5a672289c9754d07e1c3b33649786d3d70f5e4 upstream.

The mmu_notifier_release() callback of KVM triggers cleaning up
the stage2 page table on kvm-arm. However there could be other
notifier callbacks in parallel with the mmu_notifier_release(),
which could cause the call backs ending up in an empty stage2
page table. Make sure we check it for all the notifier callbacks.

Fixes: commit 293f29363 ("kvm-arm: Unmap shadow pagetables properly")
Reported-by: Alex Graf 
Reviewed-by: Christoffer Dall 
Signed-off-by: Suzuki K Poulose 
Signed-off-by: Marc Zyngier 
Signed-off-by: Greg Kroah-Hartman

vfio: New external user group/file match

2017-07-27T22:10:16+00:00

commit 5d6dee80a1e94cc284d03e06d930e60e8d3ecf7d upstream.

At the point where the kvm-vfio pseudo device wants to release its
vfio group reference, we can't always acquire a new reference to make
that happen.  The group can be in a state where we wouldn't allow a
new reference to be added.  This new helper function allows a caller
to match a file to a group to facilitate this.  Given a file and
group, report if they match.  Thus the caller needs to already have a
group reference to match to the file.  This allows the deletion of a
group without acquiring a new reference.

Signed-off-by: Alex Williamson 
Reviewed-by: Eric Auger 
Reviewed-by: Paolo Bonzini 
Tested-by: Eric Auger 
Signed-off-by: Greg Kroah-Hartman

kvm-vfio: Decouple only when we match a group

2017-07-21T04:59:08+00:00

commit e323369b2e204da4dc771bbddceef986f4bf85d5 upstream.

Unset-KVM and decrement-assignment only when we find the group in our
list.  Otherwise we can get out of sync if the user triggers this for
groups that aren't currently on our list.

Signed-off-by: Alex Williamson 
Reviewed-by: Alexey Kardashevskiy 
Reviewed-by: Eric Auger 
Tested-by: Eric Auger 
Acked-by: Paolo Bonzini 
Signed-off-by: Greg Kroah-Hartman

KVM: ARM64: fix phy counter access failure in guest.

2017-07-21T04:59:07+00:00

commit 02d50cdaff36c135d222015cffdca3ff11d168ea upstream.

When reading the cntpct_el0 in guest with VHE (Virtual Host Extension)
enabled in host, the "Unsupported guest sys_reg access" error reported.
The reason is cnthctl_el2.EL1PCTEN is not enabled, which is expected
to be done in kvm_timer_init_vhe(). The problem is kvm_timer_init_vhe
is called by cpu_init_hyp_mode, and which is called when VHE is disabled.
This patch remove the incorrect call to kvm_timer_init_vhe() from
cpu_init_hyp_mode(), and calls kvm_timer_init_vhe() to enable
cnthctl_el2.EL1PCTEN in cpu_hyp_reinit().

Fixes: 488f94d7212b ("KVM: arm64: Access CNTHCTL_EL2 bit fields correctly on VHE systems")
Signed-off-by: Hu Huajun 
Reviewed-by: Christoffer Dall 
Acked-by: Marc Zyngier 
Signed-off-by: Christoffer Dall 
Signed-off-by: Greg Kroah-Hartman

KVM: arm/arm64: Handle possible NULL stage2 pud when ageing pages

2017-06-06T13:28:40+00:00

Under memory pressure, we start ageing pages, which amounts to parsing
the page tables. Since we don't want to allocate any extra level,
we pass NULL for our private allocation cache. Which means that
stage2_get_pud() is allowed to fail. This results in the following
splat:

[ 1520.409577] Unable to handle kernel NULL pointer dereference at virtual address 00000008
[ 1520.417741] pgd = ffff810f52fef000
[ 1520.421201] [00000008] *pgd=0000010f636c5003, *pud=0000010f56f48003, *pmd=0000000000000000
[ 1520.429546] Internal error: Oops: 96000006 [#1] PREEMPT SMP
[ 1520.435156] Modules linked in:
[ 1520.438246] CPU: 15 PID: 53550 Comm: qemu-system-aar Tainted: G        W       4.12.0-rc4-00027-g1885c397eaec #7205
[ 1520.448705] Hardware name: FOXCONN R2-1221R-A4/C2U4N_MB, BIOS G31FB12A 10/26/2016
[ 1520.463726] task: ffff800ac5fb4e00 task.stack: ffff800ce04e0000
[ 1520.469666] PC is at stage2_get_pmd+0x34/0x110
[ 1520.474119] LR is at kvm_age_hva_handler+0x44/0xf0
[ 1520.478917] pc : [] lr : [] pstate: 40000145
[ 1520.486325] sp : ffff800ce04e33d0
[ 1520.489644] x29: ffff800ce04e33d0 x28: 0000000ffff40064
[ 1520.494967] x27: 0000ffff27e00000 x26: 0000000000000000
[ 1520.500289] x25: ffff81051ba65008 x24: 0000ffff40065000
[ 1520.505618] x23: 0000ffff40064000 x22: 0000000000000000
[ 1520.510947] x21: ffff810f52b20000 x20: 0000000000000000
[ 1520.516274] x19: 0000000058264000 x18: 0000000000000000
[ 1520.521603] x17: 0000ffffa6fe7438 x16: ffff000008278b70
[ 1520.526940] x15: 000028ccd8000000 x14: 0000000000000008
[ 1520.532264] x13: ffff7e0018298000 x12: 0000000000000002
[ 1520.537582] x11: ffff000009241b93 x10: 0000000000000940
[ 1520.542908] x9 : ffff0000092ef800 x8 : 0000000000000200
[ 1520.548229] x7 : ffff800ce04e36a8 x6 : 0000000000000000
[ 1520.553552] x5 : 0000000000000001 x4 : 0000000000000000
[ 1520.558873] x3 : 0000000000000000 x2 : 0000000000000008
[ 1520.571696] x1 : ffff000008fd5000 x0 : ffff0000080b149c
[ 1520.577039] Process qemu-system-aar (pid: 53550, stack limit = 0xffff800ce04e0000)
[...]
[ 1521.510735] [] stage2_get_pmd+0x34/0x110
[ 1521.516221] [] kvm_age_hva_handler+0x44/0xf0
[ 1521.522054] [] handle_hva_to_gpa+0xb8/0xe8
[ 1521.527716] [] kvm_age_hva+0x44/0xf0
[ 1521.532854] [] kvm_mmu_notifier_clear_flush_young+0x70/0xc0
[ 1521.539992] [] __mmu_notifier_clear_flush_young+0x88/0xd0
[ 1521.546958] [] page_referenced_one+0xf0/0x188
[ 1521.552881] [] rmap_walk_anon+0xec/0x250
[ 1521.558370] [] rmap_walk+0x78/0xa0
[ 1521.563337] [] page_referenced+0x164/0x180
[ 1521.569002] [] shrink_active_list+0x178/0x3b8
[ 1521.574922] [] shrink_node_memcg+0x328/0x600
[ 1521.580758] [] shrink_node+0xc4/0x328
[ 1521.585986] [] do_try_to_free_pages+0xc0/0x340
[ 1521.592000] [] try_to_free_pages+0xcc/0x240
[...]

The trivial fix is to handle this NULL pud value early, rather than
dereferencing it blindly.

Cc: stable@vger.kernel.org
Signed-off-by: Marc Zyngier 
Reviewed-by: Christoffer Dall 
Signed-off-by: Christoffer Dall

KVM: arm/arm64: vgic-v3: Fix nr_pre_bits bitfield extraction

2017-06-06T08:16:53+00:00

We used to extract PRIbits from the ICH_VT_EL2 which was the upper field
in the register word, so a mask wasn't necessary, but as we switched to
looking at PREbits, which is bits 26 through 28 with the PRIbits field
being potentially non-zero, we really need to mask off the field value,
otherwise fun things may happen.

Signed-off-by: Christoffer Dall 
Acked-by: Marc Zyngier

KVM: arm/arm64: Fix isues with GICv2 on GICv3 migration

2017-05-24T07:44:07+00:00

We have been a little loose with our intermediate VMCR representation
where we had a 'ctlr' field, but we failed to differentiate between the
GICv2 GICC_CTLR and ICC_CTLR_EL1 layouts, and therefore ended up mapping
the wrong bits into the individual fields of the ICH_VMCR_EL2 when
emulating a GICv2 on a GICv3 system.

Fix this by using explicit fields for the VMCR bits instead.

Cc: Eric Auger 
Reported-by: wanghaibin 
Signed-off-by: Christoffer Dall 
Reviewed-by: Marc Zyngier 
Tested-by: Marc Zyngier

KVM: arm/arm64: Hold slots_lock when unregistering kvm io bus devices

2017-05-18T09:18:16+00:00

We were not holding the kvm->slots_lock as required when calling
kvm_io_bus_unregister_dev() as required.

This only affects the error path, but still, let's do our due
diligence.

Reported by: Eric Auger 
Signed-off-by: Christoffer Dall 
Reviewed-by: Eric Auger

KVM: arm/arm64: Fix bug when registering redist iodevs

2017-05-18T09:18:12+00:00

If userspace creates the VCPUs after initializing the VGIC, then we end
up in a situation where we trigger a bug in kvm_vcpu_get_idx(), because
it is called prior to adding the VCPU into the vcpus array on the VM.

There is no tight coupling between the VCPU index and the area of the
redistributor region used for the VCPU, so we can simply ensure that all
creations of redistributors are serialized per VM, and increment an
offset when we successfully add a redistributor.

The vgic_register_redist_iodev() function can be called from two paths:
vgic_redister_all_redist_iodev() which is called via the kvm_vgic_addr()
device attribute handler.  This patch already holds the kvm->lock mutex.

The other path is via kvm_vgic_vcpu_init, which is called through a
longer chain from kvm_vm_ioctl_create_vcpu(), which releases the
kvm->lock mutex just before calling kvm_arch_vcpu_create(), so we can
simply take this mutex again later for our purposes.

Fixes: ab6f468c10 ("KVM: arm/arm64: Register iodevs when setting redist base and creating VCPUs")
Signed-off-by: Christoffer Dall 
Tested-by: Jean-Philippe Brucker 
Reviewed-by: Eric Auger

kvm: arm/arm64: Fix use after free of stage2 page table

2017-05-16T09:54:25+00:00

We yield the kvm->mmu_lock occassionaly while performing an operation
(e.g, unmap or permission changes) on a large area of stage2 mappings.
However this could possibly cause another thread to clear and free up
the stage2 page tables while we were waiting for regaining the lock and
thus the original thread could end up in accessing memory that was
freed. This patch fixes the problem by making sure that the stage2
pagetable is still valid after we regain the lock. The fact that
mmu_notifer->release() could be called twice (via __mmu_notifier_release
and mmu_notifier_unregsister) enhances the possibility of hitting
this race where there are two threads trying to unmap the entire guest
shadow pages.

While at it, cleanup the redudant checks around cond_resched_lock in
stage2_wp_range(), as cond_resched_lock already does the same checks.

Cc: Mark Rutland 
Cc: Radim Krčmář 
Cc: andreyknvl@google.com
Cc: Paolo Bonzini 
Cc: stable@vger.kernel.org
Acked-by: Marc Zyngier 
Signed-off-by: Suzuki K Poulose 
Reviewed-by: Christoffer Dall 
Signed-off-by: Christoffer Dall