[PATCH 1/2] drivers/vfio: Support EEH API revision

This extends the return value from container's IOCTL command (VFIO_CHECK_EXTENSION + VFIO_EEH) to EEH API revision. Also, extra check is applied to return -ENOTTY if EEH functionality is disabled in vfio_spapr_iommu_eeh_ioctl(). Signed-off-by: Gavin Shan ---

[PATCH 2/2] drivers/vfio: Support IOMMU group for EEH operations

Currently, EEH module works based on the assumption that every container has only one attached IOMMU group. It's not true any more. So the userland has to specify the IOMMU group (PE) to which the requested EEH operation is applied. This exposes "v2" interface for the userland to specify IOMMU

[PATCH] KVM: PPC: Book3S HV: Fix handling of interrupted VCPUs

This fixes a bug which results in stale vcore pointers being left in the per-cpu preempted vcore lists when a VM is destroyed. The result of the stale vcore pointers is usually either a crash or a lockup inside collect_piggybacks() when another VM is run. A typical lockup message looks like: [

Re: [PATCH v4] ppc/spapr: Implement H_RANDOM hypercall in QEMU

On Thu, 17 Sep 2015 10:49:41 +0200 Thomas Huth wrote: > The PAPR interface defines a hypercall to pass high-quality > hardware generated random numbers to guests. Recent kernels can > already provide this hypercall to the guest if the right hardware > random number generator is

Re: [PATCH] KVM: PPC: Book3S HV: Fix handling of interrupted VCPUs

On 18/09/15 08:57, Paul Mackerras wrote: > This fixes a bug which results in stale vcore pointers being left in > the per-cpu preempted vcore lists when a VM is destroyed. The result > of the stale vcore pointers is usually either a crash or a lockup > inside collect_piggybacks() when another VM

Re: suspicious RCU usage with kvm_pr

On 9/18/15, Thomas Huth wrote: > On 16/09/15 12:59, Denis Kirjanov wrote: >> On 9/16/15, Thomas Huth wrote: >>> On 16/09/15 10:51, Denis Kirjanov wrote: Hi, I see the following trace on qemu startup (ps700 blade): v4.2-11169-g64d1def

[PATCH] KVM: PPC: Take the kvm->srcu lock in kvmppc_h_logical_ci_load/store()

Access to the kvm->buses (like with the kvm_io_bus_read() and -write() functions) has to be protected via the kvm->srcu lock. The kvmppc_h_logical_ci_load() and -store() functions are missing this lock so far, so let's add it there, too. This fixes the problem that the kernel reports "suspicious

Re: suspicious RCU usage with kvm_pr

On 16/09/15 12:59, Denis Kirjanov wrote: > On 9/16/15, Thomas Huth wrote: >> On 16/09/15 10:51, Denis Kirjanov wrote: >>> Hi, >>> >>> I see the following trace on qemu startup (ps700 blade): >>> >>> v4.2-11169-g64d1def >>> >>> >>> [ 143.369638] ===

Re: [PATCH 0/2] VFIO: Accept IOMMU group (PE) ID

On Fri, 2015-09-18 at 16:24 +1000, Gavin Shan wrote: > This allows to accept IOMMU group (PE) ID from the parameter from userland > when handling EEH operation so that the operation only affects the target > IOMMU group (PE). If the IOMMU group (PE) ID in the parameter from userland > is invalid,