linux-toradex.git/Documentation/virtual, branch v3.18.14

KVM: s390: fix get_all_floating_irqs

2015-05-17T23:11:49+00:00

[ Upstream commit 94aa033efcac47b09db22cb561e135baf37b7887 ]

This fixes a bug introduced with commit c05c4186bbe4 ("KVM: s390:
add floating irq controller").

get_all_floating_irqs() does copy_to_user() while holding
a spin lock. Let's fix this by filling a temporary buffer
first and copy it to userspace after giving up the lock.

Cc:  # 3.18+: 69a8d4562638 KVM: s390: no need to hold...

Reviewed-by: David Hildenbrand 
Signed-off-by: Jens Freimann 
Signed-off-by: Christian Borntraeger 
Acked-by: Cornelia Huck 
Signed-off-by: Sasha Levin

arm/arm64: KVM: Turn off vcpus on PSCI shutdown/reboot

2015-05-11T11:07:32+00:00

commit cf5d318865e25f887d49a0c6083bbc6dcd1905b1 upstream.

When a vcpu calls SYSTEM_OFF or SYSTEM_RESET with PSCI v0.2, the vcpus
should really be turned off for the VM adhering to the suggestions in
the PSCI spec, and it's the sane thing to do.

Also, clarify the behavior and expectations for exits to user space with
the KVM_EXIT_SYSTEM_EVENT case.

Acked-by: Marc Zyngier 
Signed-off-by: Christoffer Dall 
Signed-off-by: Shannon Zhao 
Signed-off-by: Sasha Levin

arm/arm64: KVM: Correct KVM_ARM_VCPU_INIT power off option

2015-05-11T11:07:31+00:00

commit 3ad8b3de526a76fbe9466b366059e4958957b88f upstream.

The implementation of KVM_ARM_VCPU_INIT is currently not doing what
userspace expects, namely making sure that a vcpu which may have been
turned off using PSCI is returned to its initial state, which would be
powered on if userspace does not set the KVM_ARM_VCPU_POWER_OFF flag.

Implement the expected functionality and clarify the ABI.

Acked-by: Marc Zyngier 
Signed-off-by: Christoffer Dall 
Signed-off-by: Shannon Zhao 
Signed-off-by: Sasha Levin

Merge tag 'kvm-arm-for-3.18' of git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into kvm-next

2014-09-27T09:03:33+00:00

Changes for KVM for arm/arm64 for 3.18

This includes a bunch of changes:
 - Support read-only memory slots on arm/arm64
 - Various changes to fix Sparse warnings
 - Correctly detect write vs. read Stage-2 faults
 - Various VGIC cleanups and fixes
 - Dynamic VGIC data strcuture sizing
 - Fix SGI set_clear_pend offset bug
 - Fix VTTBR_BADDR Mask
 - Correctly report the FSC on Stage-2 faults

Conflicts:
	virt/kvm/eventfd.c
	[duplicate, different patch where the kvm-arm version broke x86.
	 The kvm tree instead has the right one]

KVM: PPC: BOOKE: Add one_reg documentation of SPRG9 and DBSR

2014-09-22T08:11:32+00:00

This was missed in respective one_reg implementation patch.

Signed-off-by: Bharat Bhushan 
Signed-off-by: Alexander Graf

arm/arm64: KVM: vgic: make number of irqs a configurable attribute

2014-09-19T01:48:58+00:00

In order to make the number of interrupts configurable, use the new
fancy device management API to add KVM_DEV_ARM_VGIC_GRP_NR_IRQS as
a VGIC configurable attribute.

Userspace can now specify the exact size of the GIC (by increments
of 32 interrupts).

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

KVM: fix api documentation of KVM_GET_EMULATED_CPUID

2014-09-10T09:34:39+00:00

It looks like when this was initially merged it got accidentally included
in the following section. I've just moved it back in the correct section
and re-numbered it as other ioctls have been added since.

Signed-off-by: Alex BennÃ©e 
Acked-by: Borislav Petkov 
Signed-off-by: Paolo Bonzini

KVM: document KVM_SET_GUEST_DEBUG api

2014-09-10T09:33:12+00:00

In preparation for working on the ARM implementation I noticed the debug
interface was missing from the API document. I've pieced together the
expected behaviour from the code and commit messages written it up as
best I can.

Signed-off-by: Alex BennÃ©e 
Signed-off-by: Paolo Bonzini

kvm: fix potentially corrupt mmio cache

2014-09-03T08:03:41+00:00

vcpu exits and memslot mutations can run concurrently as long as the
vcpu does not aquire the slots mutex. Thus it is theoretically possible
for memslots to change underneath a vcpu that is handling an exit.

If we increment the memslot generation number again after
synchronize_srcu_expedited(), vcpus can safely cache memslot generation
without maintaining a single rcu_dereference through an entire vm exit.
And much of the x86/kvm code does not maintain a single rcu_dereference
of the current memslots during each exit.

We can prevent the following case:

   vcpu (CPU 0)                             | thread (CPU 1)
--------------------------------------------+--------------------------
1  vm exit                                  |
2  srcu_read_unlock(&kvm->srcu)             |
3  decide to cache something based on       |
     old memslots                           |
4                                           | change memslots
                                            | (increments generation)
5                                           | synchronize_srcu(&kvm->srcu);
6  retrieve generation # from new memslots  |
7  tag cache with new memslot generation    |
8  srcu_read_unlock(&kvm->srcu)             |
...                                         |
                       |
...                                         |
                                  |
                                            |

By incrementing the generation after synchronizing with kvm->srcu readers,
we ensure that the generation retrieved in (6) will become invalid soon
after (8).

Keeping the existing increment is not strictly necessary, but we
do keep it and just move it for consistency from update_memslots to
install_new_memslots.  It invalidates old cached MMIOs immediately,
instead of having to wait for the end of synchronize_srcu_expedited,
which makes the code more clearly correct in case CPU 1 is preempted
right after synchronize_srcu() returns.

To avoid halving the generation space in SPTEs, always presume that the
low bit of the generation is zero when reconstructing a generation number
out of an SPTE.  This effectively disables MMIO caching in SPTEs during
the call to synchronize_srcu_expedited.  Using the low bit this way is
somewhat like a seqcount---where the protected thing is a cache, and
instead of retrying we can simply punt if we observe the low bit to be 1.

Cc: stable@vger.kernel.org
Signed-off-by: David Matlack 
Reviewed-by: Xiao Guangrong 
Reviewed-by: David Matlack 
Signed-off-by: Paolo Bonzini

KVM: clarify the idea of kvm_dirty_regs

2014-08-25T12:35:29+00:00

This patch clarifies that kvm_dirty_regs are just a hint to the kernel and
that the kernel might just ignore some flags and sync the values (like done for
acrs and gprs now).

Signed-off-by: David Hildenbrand 
Reviewed-by: Cornelia Huck 
Signed-off-by: Christian Borntraeger