[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 0/2] VFIO: Accept IOMMU group (PE) ID

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, all IOMMU groups (PEs) attached to the specified container

[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 ---

Re: [PATCH v9 00/18] Add VT-d Posted-Interrupts support - including prerequisite series

On Fri, 2015-09-18 at 16:58 +0200, Paolo Bonzini wrote: > > On 18/09/2015 16:29, Feng Wu wrote: > > VT-d Posted-Interrupts is an enhancement to CPU side Posted-Interrupt. > > With VT-d Posted-Interrupts enabled, external interrupts from > > direct-assigned devices can be delivered to guests

Re: [PATCH] irq_remapping: move structs outside #ifdef

On Fri, 18 Sep 2015, Paolo Bonzini wrote: > This is friendlier to clients of the code, who are going to prepare > vcpu_data structs unconditionally, even if CONFIG_IRQ_REMAP is not > defined. > > Signed-off-by: Paolo Bonzini Reviewed-by: Thomas Gleixner

Re: rdmsr_safe in Linux PV (under Xen) gets an #GP:Re: [Fedora-xen] Running fedora xen on top of KVM?

On Fri, Sep 18, 2015 at 08:20:46AM -0700, Andy Lutomirski wrote: > In any event, Borislav, you must have typed rdmsr_safe for a reason :) Wasn't me: 6c62aa4a3c12 ("x86: make amd.c have 64bit support code") I think the error handling of rdmsrl_safe() was needed to do the pfn games which are done

RE: KVM: MTRR: fix memory type handling if MTRR is completely disabled

Hello, I am writting about this patch that was posted by Xiao: http://www.spinics.net/lists/kvm/msg119044.html and this: http://www.spinics.net/lists/kvm/msg119045.html I've tested both kernel 4.2 and 4.3 and problem still exists when I use OVMF - 100% cpu usage, VM resetting, while it works

[PATCH] sched: access local runqueue directly in single_task_running

Commit 2ee507c47293 ("sched: Add function single_task_running to let a task check if it is the only task running on a cpu") referenced the current runqueue with the smp_processor_id. When CONFIG_DEBUG_PREEMPT is enabled, that is only allowed if preemption is disabled or the currrent task is bound

[PATCH 0/1] macvtap regression since 3.18

Michael, here is a fixup for macvtap. It was detected by running several different patterns via uperf over multiple network cards. Within some minutes, the network traffic stalled and Matt bisected it down to 39ec7de7092b ("macvtap: fix uninitialized access on TUNSETIFF"). Turns out that this

[PATCH 1/1] macvtap: Fix regression for macvtap ioctls

To avoid overwriting the upper bits of the flags, commit 39ec7de7092b ("macvtap: fix uninitialized access on TUNSETIFF") changed the variable u from unsigned int to unsigned short and added some ORing logic for the flags. This introduced at least one regression: - TUNSETSNDBUF supports int as its

Re: [PATCH] kvmtool: don't rely on $HOME

Hello, On 17 September 2015 at 15:03, Alban Crequy wrote: > kvm__set_dir() called in main() and kvm__get_dir() rely on $HOME. But in > some environments (such as starting lkvm through systemd-run), $HOME is > undefined. This causes bind() to use a socket path containing

[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 1/2] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

* Andy Lutomirski wrote: > This demotes an OOPS and likely panic due to a failed non-"safe" MSR > access to a WARN_ON_ONCE and a return of poisoned values (in the > RDMSR case). We still write a pr_info entry unconditionally for > debugging. > > To be clear, this type of

Re: [PATCH] kvmtool: don't rely on $HOME

2015-09-17 18:53 GMT+03:00 Will Deacon : > > On Thu, Sep 17, 2015 at 03:03:15PM +0100, Alban Crequy wrote: > > kvm__set_dir() called in main() and kvm__get_dir() rely on $HOME. But in > > some environments (such as starting lkvm through systemd-run), $HOME is > > undefined.

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: [edk2] KVM: MTRR: fix memory type handling if MTRR is completely disabled

On 09/18/15 11:37, Janusz wrote: > Hello, > > I am writting about this patch that was posted by Xiao: > http://www.spinics.net/lists/kvm/msg119044.html and this: > http://www.spinics.net/lists/kvm/msg119045.html > I've tested both kernel 4.2 and 4.3 and problem still exists when I use > OVMF -

Re: rdmsr_safe in Linux PV (under Xen) gets an #GP:Re: [Fedora-xen] Running fedora xen on top of KVM?

On 09/18/2015 03:04 PM, Borislav Petkov wrote: > On Fri, Sep 18, 2015 at 08:20:46AM -0700, Andy Lutomirski wrote: >> Given that we can handle fixups in the decompressor, surely it >> wouldn't be so hard to make early GPF fixups work in the main kernel. > > Frankly, I still am wondering what a

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

Re: [PATCH] KVM: x86: trap AMD MSRs for the TSeg base and mask

On Fri, Sep 18, 2015 at 05:34:24PM +0200, Paolo Bonzini wrote: > These have roughly the same purpose as the SMRR, which we do not need > to implement in KVM. However, Linux accesses MSR_K8_TSEG_ADDR at > boot, which causes problems when running a Xen dom0 under KVM. > Just return 0, meaning that

Re: [edk2] KVM: MTRR: fix memory type handling if MTRR is completely disabled

W dniu 18.09.2015 o 12:07, Laszlo Ersek pisze: > On 09/18/15 11:37, Janusz wrote: >> Hello, >> >> I am writting about this patch that was posted by Xiao: >> http://www.spinics.net/lists/kvm/msg119044.html and this: >> http://www.spinics.net/lists/kvm/msg119045.html >> I've tested both kernel 4.2

Re: [PATCH 1/1] macvtap: Fix regression for macvtap ioctls

On Fri, Sep 18, 2015 at 09:54:44AM +0200, Christian Borntraeger wrote: > To avoid overwriting the upper bits of the flags, commit > 39ec7de7092b ("macvtap: fix uninitialized access on > TUNSETIFF") changed the variable u from unsigned int to > unsigned short and added some ORing logic for the

[PULL] vhost: cleanups and fixes

The following changes since commit 997e120843e82609c8d99a9d5714e6cf91e14cbe: virtio_balloon: do not change memory amount visible via /proc/meminfo (2015-09-08 13:32:11 +0300) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git tags/for_linus

Re: [PATCH] KVM: disable halt_poll_ns as default for s390x

Am 18.09.2015 um 12:34 schrieb David Hildenbrand: > We observed some performance degradation on s390x with dynamic > halt polling. Until we can provide a proper fix, let's enable > halt_poll_ns as default only for supported architectures. > > Architectures are now free to set their own

Re: [PATCH] kvmtool: don't rely on $HOME

On Fri, Sep 18, 2015 at 11:51:37AM +0100, Riku Voipio wrote: > On 17 September 2015 at 18:53, Will Deacon wrote: > > On Thu, Sep 17, 2015 at 03:03:15PM +0100, Alban Crequy wrote: > >> kvm__set_dir() called in main() and kvm__get_dir() rely on $HOME. But in > >> some

Re: [PATCH] sched: access local runqueue directly in single_task_running

On Fri, 18 Sep 2015 13:26:53 +0200 Paolo Bonzini wrote: > > > On 18/09/2015 11:27, Dominik Dingel wrote: > > Commit 2ee507c47293 ("sched: Add function single_task_running to let a task > > check if it is the only task running on a cpu") referenced the current > > runqueue

Re: [PATCH] KVM: disable halt_poll_ns as default for s390x

Am 18.09.2015 um 13:29 schrieb Paolo Bonzini: > > > On 18/09/2015 12:54, Christian Borntraeger wrote: >>> -/* halt polling only reduces halt latency by 5-7 us, 500us is enough */ >>> -static unsigned int halt_poll_ns = 50; >>> +/* Architectures should define their poll value according to the

Re: [PATCH] sched: access local runqueue directly in single_task_running

On Fri, Sep 18, 2015 at 01:26:53PM +0200, Paolo Bonzini wrote: > > +++ b/kernel/sched/core.c > > @@ -2614,13 +2614,13 @@ unsigned long nr_running(void) > > > > /* > > * Check if only the current task is running on the cpu. > > + * > > + * Caution result is subject to

Re: [PATCH] KVM: disable halt_poll_ns as default for s390x

On 18/09/2015 12:54, Christian Borntraeger wrote: > > -/* halt polling only reduces halt latency by 5-7 us, 500us is enough */ > > -static unsigned int halt_poll_ns = 50; > > +/* Architectures should define their poll value according to the halt > > latency */ > > +static unsigned int

[GIT PULL] KVM fixes for 4.3-rc2

Linus, The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f: Linux 4.3-rc1 (2015-09-12 16:35:56 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-linus for you to fetch changes up to

[PATCH] KVM: disable halt_poll_ns as default for s390x

We observed some performance degradation on s390x with dynamic halt polling. Until we can provide a proper fix, let's enable halt_poll_ns as default only for supported architectures. Architectures are now free to set their own halt_poll_ns default value. Signed-off-by: David Hildenbrand

Re: [PATCH] kvmtool: don't rely on $HOME

On 17 September 2015 at 18:53, Will Deacon wrote: > On Thu, Sep 17, 2015 at 03:03:15PM +0100, Alban Crequy wrote: >> kvm__set_dir() called in main() and kvm__get_dir() rely on $HOME. But in >> some environments (such as starting lkvm through systemd-run), $HOME is >>

Re: [PATCH] sched: access local runqueue directly in single_task_running

On 18/09/2015 11:27, Dominik Dingel wrote: > Commit 2ee507c47293 ("sched: Add function single_task_running to let a task > check if it is the only task running on a cpu") referenced the current > runqueue with the smp_processor_id. When CONFIG_DEBUG_PREEMPT is enabled, > that is only allowed if

[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: [PATCH] kvmtool: don't rely on $HOME

On 18 September 2015 at 09:59, Vasiliy Tolstov wrote: > 2015-09-17 18:53 GMT+03:00 Will Deacon : >> >> On Thu, Sep 17, 2015 at 03:03:15PM +0100, Alban Crequy wrote: >> > kvm__set_dir() called in main() and kvm__get_dir() rely on $HOME. But in >> > some

[PATCH v9 15/18] KVM: Add an arch specific hooks in 'struct kvm_kernel_irqfd'

This patch adds an arch specific hooks 'arch_update' in 'struct kvm_kernel_irqfd'. On Intel side, it is used to update the IRTE when VT-d posted-interrupts is used. Signed-off-by: Feng Wu --- v9: - Use 'if' instead of "? :" in kvm_arch_update_irqfd_routing() - coding style

[PATCH v9 09/18] KVM: Define a new interface kvm_intr_is_single_vcpu()

This patch defines a new interface kvm_intr_is_single_vcpu(), which can returns whether the interrupt is for single-CPU or not. It is used by VT-d PI, since now we only support single-CPU interrupts, For lowest-priority interrupts, if user configures it via /proc/irq or uses irqbalance to make it

[PATCH v9 13/18] KVM: x86: Update IRTE for posted-interrupts

This patch adds the routine to update IRTE for posted-interrupts when guest changes the interrupt configuration. Signed-off-by: Feng Wu --- v9: - Check !kvm_arch_has_assigned_device(kvm) first then !irq_remapping_cap(IRQ_POSTING_CAP) v8: - Move 'kvm_arch_update_pi_irte' to

[PATCH v9 10/18] KVM: Make struct kvm_irq_routing_table accessible

Move struct kvm_irq_routing_table from irqchip.c to kvm_host.h, so we can use it outside of irqchip.c. Signed-off-by: Feng Wu Reviewed-by: Paolo Bonzini --- include/linux/kvm_host.h | 14 ++ virt/kvm/irqchip.c | 10 -- 2 files

Re: [PATCH] kvm: svm: reset mmu on VCPU reset

On 18/09/2015 15:39, Igor Mammedov wrote: > When INIT/SIPI sequence is sent to VCPU which before that > was in use by OS, VMRUN might fail with: > > KVM: entry failed, hardware error 0x > EAX= EBX= ECX= EDX=06d3 > ESI= EDI= EBP=

[PATCH v9 00/18] Add VT-d Posted-Interrupts support - including prerequisite series

VT-d Posted-Interrupts is an enhancement to CPU side Posted-Interrupt. With VT-d Posted-Interrupts enabled, external interrupts from direct-assigned devices can be delivered to guests without VMM intervention when guest is running in non-root mode. You can find the VT-d Posted-Interrtups Spec. in

Re: [kbuild-all] [kvm:queue 27/38] arch/x86/kvm/hyperv.c:186:41: sparse: incorrect type in argument 2 (different modifiers)

[CC sparse people] On Fri, Sep 18, 2015 at 04:41:56PM +0200, Paolo Bonzini wrote: > > > On 18/09/2015 16:40, Roman Kagan wrote: > > typedef unsigned long __nocast cputime_t; > > > > extern void task_cputime_adjusted(cputime_t *); > > extern void current_task_runtime_100ns(void); > > > > void

Re: [kvm:queue 27/38] arch/x86/kvm/hyperv.c:186:41: sparse: incorrect type in argument 2 (different modifiers)

On 18/09/2015 16:40, Roman Kagan wrote: > typedef unsigned long __nocast cputime_t; > > extern void task_cputime_adjusted(cputime_t *); > extern void current_task_runtime_100ns(void); > > void current_task_runtime_100ns(void) > { > cputime_t utime; > > task_cputime_adjusted();

[PATCH v9 18/18] iommu/vt-d: Add a command line parameter for VT-d posted-interrupts

Enable VT-d Posted-Interrtups and add a command line parameter for it. Signed-off-by: Feng Wu Reviewed-by: Paolo Bonzini --- Documentation/kernel-parameters.txt | 1 + drivers/iommu/irq_remapping.c | 12 2 files changed, 9

[PATCH v9 17/18] KVM: Update Posted-Interrupts Descriptor when vCPU is blocked

This patch updates the Posted-Interrupts Descriptor when vCPU is blocked. pre-block: - Add the vCPU to the blocked per-CPU list - Set 'NV' to POSTED_INTR_WAKEUP_VECTOR post-block: - Remove the vCPU from the per-CPU list Signed-off-by: Feng Wu --- v9: - Add description for

[PATCH v9 07/18] KVM: Extend struct pi_desc for VT-d Posted-Interrupts

Extend struct pi_desc for VT-d Posted-Interrupts. Signed-off-by: Feng Wu --- arch/x86/kvm/vmx.c | 20 ++-- 1 file changed, 18 insertions(+), 2 deletions(-) diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c index 83b7b5c..271dd70 100644 ---

[PATCH v9 11/18] KVM: make kvm_set_msi_irq() public

Make kvm_set_msi_irq() public, we can use this function outside. Signed-off-by: Feng Wu Reviewed-by: Paolo Bonzini --- v8: - Export kvm_set_msi_irq() so we can use it in vmx code arch/x86/include/asm/kvm_host.h | 4 arch/x86/kvm/irq_comm.c

[PATCH v9 08/18] KVM: Add some helper functions for Posted-Interrupts

This patch adds some helper functions to manipulate the Posted-Interrupts Descriptor. Signed-off-by: Feng Wu Reviewed-by: Paolo Bonzini --- arch/x86/kvm/vmx.c | 26 ++ 1 file changed, 26 insertions(+) diff --git

[PATCH v9 04/18] KVM: create kvm_irqfd.h

From: Eric Auger Move _irqfd_resampler and _irqfd struct declarations in a new public header: kvm_irqfd.h. They are respectively renamed into kvm_kernel_irqfd_resampler and kvm_kernel_irqfd. Those datatypes will be used by architecture specific code, in the context of IRQ

[PATCH v9 03/18] KVM: arm/arm64: select IRQ_BYPASS_MANAGER

From: Eric Auger Select IRQ_BYPASS_MANAGER when CONFIG_KVM is set Also add compilation of virt/lib. Signed-off-by: Eric Auger Signed-off-by: Feng Wu --- v3 -> v4: - add compilation of virt/lib in arm/arm64 KVM v2 -> v3: - [Feng

Re: [kvm:queue 27/38] arch/x86/kvm/hyperv.c:186:41: sparse: incorrect type in argument 2 (different modifiers)

On Fri, Sep 18, 2015 at 03:55:00PM +0200, Paolo Bonzini wrote: > > > On 18/09/2015 15:51, Denis V. Lunev wrote: > >> 185 > >> > 186task_cputime_adjusted(current, , ); > >> 187return div_u64(cputime_to_nsecs(utime + stime), 100); > >> 188} > >> 189 > >>

[PATCH v9 12/18] vfio: Register/unregister irq_bypass_producer

This patch adds the registration/unregistration of an irq_bypass_producer for MSI/MSIx on vfio pci devices. Signed-off-by: Feng Wu --- v8: - Merge "[PATCH v7 08/17] vfio: Select IRQ_BYPASS_MANAGER for vfio PCI devices" into this patch. v6: - Make the add_consumer and

[PATCH v9 14/18] KVM: Implement IRQ bypass consumer callbacks for x86

Implement the following callbacks for x86: - kvm_arch_irq_bypass_add_producer - kvm_arch_irq_bypass_del_producer - kvm_arch_irq_bypass_stop: dummy callback - kvm_arch_irq_bypass_resume: dummy callback and set CONFIG_HAVE_KVM_IRQ_BYPASS for x86. Signed-off-by: Feng Wu --- v8:

[PATCH v9 16/18] KVM: Update Posted-Interrupts Descriptor when vCPU is preempted

This patch updates the Posted-Interrupts Descriptor when vCPU is preempted. sched out: - Set 'SN' to suppress furture non-urgent interrupts posted for the vCPU. sched in: - Clear 'SN' - Change NDST if vCPU is scheduled to a different CPU - Set 'NV' to POSTED_INTR_VECTOR Signed-off-by: Feng Wu

[PATCH v9 06/18] KVM: eventfd: add irq bypass consumer management

From: Eric Auger This patch adds the registration/unregistration of an irq_bypass_consumer on irqfd assignment/deassignment. Signed-off-by: Eric Auger Signed-off-by: Feng Wu --- v4 -> v5: - due to removal of static inline stubs,

[PATCH v9 01/18] virt: IRQ bypass manager

From: Alex Williamson When a physical I/O device is assigned to a virtual machine through facilities like VFIO and KVM, the interrupt for the device generally bounces through the host system before being injected into the VM. However, hardware technologies exist that

[PATCH v9 05/18] KVM: introduce kvm_arch functions for IRQ bypass

From: Eric Auger This patch introduces - kvm_arch_irq_bypass_add_producer - kvm_arch_irq_bypass_del_producer - kvm_arch_irq_bypass_stop - kvm_arch_irq_bypass_start They make possible to specialize the KVM IRQ bypass consumer in case CONFIG_KVM_HAVE_IRQ_BYPASS is set.

Re: [PATCH] kvm:x86:Fix incorrect error paths in the function process_smi

On 18/09/2015 16:46, Nicholas Krause wrote: > This fixes the incorrect assumation that the function > kvm_vcpu_write_guest always runs successfully and > therefore checks if it fails by returning a error code > and if so return immediately to the caller of the function > process_smi as we cannot

[PATCH v9 02/18] KVM: x86: select IRQ_BYPASS_MANAGER

Select IRQ_BYPASS_MANAGER for x86 when CONFIG_KVM is set Signed-off-by: Feng Wu --- arch/x86/kvm/Kconfig | 2 ++ arch/x86/kvm/Makefile | 3 +++ 2 files changed, 5 insertions(+) diff --git a/arch/x86/kvm/Kconfig b/arch/x86/kvm/Kconfig index d8a1d56..c951d44 100644 ---

Re: [PATCH v9 00/18] Add VT-d Posted-Interrupts support - including prerequisite series

On 18/09/2015 16:29, Feng Wu wrote: > VT-d Posted-Interrupts is an enhancement to CPU side Posted-Interrupt. > With VT-d Posted-Interrupts enabled, external interrupts from > direct-assigned devices can be delivered to guests without VMM > intervention when guest is running in non-root mode. >

RE: [PATCH v9 00/18] Add VT-d Posted-Interrupts support - including prerequisite series

> -Original Message- > From: Paolo Bonzini [mailto:pbonz...@redhat.com] > Sent: Friday, September 18, 2015 10:59 PM > To: Wu, Feng; alex.william...@redhat.com; j...@8bytes.org; > mtosa...@redhat.com > Cc: eric.au...@linaro.org; kvm@vger.kernel.org; > io...@lists.linux-foundation.org;

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: [kvm:queue 27/38] arch/x86/kvm/hyperv.c:186:41: sparse: incorrect type in argument 2 (different modifiers)

On 18/09/2015 15:51, Denis V. Lunev wrote: >> 185 >> > 186task_cputime_adjusted(current, , ); >> 187return div_u64(cputime_to_nsecs(utime + stime), 100); >> 188} >> 189 >> 190static int kvm_hv_set_msr(struct kvm_vcpu *vcpu, u32 msr, >> u64

Re: [kvm:queue 27/38] arch/x86/kvm/hyperv.c:186:41: sparse: incorrect type in argument 2 (different modifiers)

On 09/18/2015 04:55 PM, Paolo Bonzini wrote: On 18/09/2015 15:51, Denis V. Lunev wrote: 185 > 186task_cputime_adjusted(current, , ); 187return div_u64(cputime_to_nsecs(utime + stime), 100); 188} 189 190static int kvm_hv_set_msr(struct

Re: [kvm:queue 27/38] arch/x86/kvm/hyperv.c:186:41: sparse: incorrect type in argument 2 (different modifiers)

On 09/18/2015 04:39 PM, kbuild test robot wrote: tree: https://git.kernel.org/pub/scm/virt/kvm/kvm.git queue head: ed393e4134de0dd02d8ba98ca8ce3ae65d1eb567 commit: 46f4c309534b10ca1026273abe38955d3cff4023 [27/38] kvm/x86: Hyper-V HV_X64_MSR_VP_RUNTIME support reproduce: # apt-get install

[kvm:queue 27/38] arch/x86/kvm/hyperv.c:186:41: sparse: incorrect type in argument 2 (different modifiers)

tree: https://git.kernel.org/pub/scm/virt/kvm/kvm.git queue head: ed393e4134de0dd02d8ba98ca8ce3ae65d1eb567 commit: 46f4c309534b10ca1026273abe38955d3cff4023 [27/38] kvm/x86: Hyper-V HV_X64_MSR_VP_RUNTIME support reproduce: # apt-get install sparse git checkout

[PATCH] kvm: svm: reset mmu on VCPU reset

When INIT/SIPI sequence is sent to VCPU which before that was in use by OS, VMRUN might fail with: KVM: entry failed, hardware error 0x EAX= EBX= ECX= EDX=06d3 ESI= EDI= EBP= ESP= EIP= EFL=0002 [---] CPL=0

Re: rdmsr_safe in Linux PV (under Xen) gets an #GP:Re: [Fedora-xen] Running fedora xen on top of KVM?

On Thu, Sep 17, 2015 at 01:23:31PM -0700, Andy Lutomirski wrote: > Cc: Borislav. Is TSEG guaranteed to exist? Can we defer that until Why not? It is the tseg base address. I think this is kvm injecting a #GP as it is not ignoring this MSR. Presumably modprobing kvm with "ignore_msrs=1" or so

Re: single_task_running() vs. preemption warnings (was Re: [PATCH] kvm: fix preemption warnings in kvm_vcpu_block)

On Thu, Sep 17, 2015 at 01:32:55PM -0700, Tim Chen wrote: > I have no objection to change single_task_running to use > raw_smp_processor_id. The worker in mcryptd is bound to > the cpu so it has no migration/preemption issue. So it shouldn't care > which smp_processor_id version is being used.

Re: [PATCH v8 03/13] KVM: Define a new interface kvm_intr_is_single_vcpu()

2015-09-17 23:18+, Wu, Feng: >> From: Paolo Bonzini [mailto:pbonz...@redhat.com] >> On 17/09/2015 17:58, Radim Krčmář wrote: >>> xAPIC address are only 8 bit long so they always get delivered to x2APIC >>> cluster 0, where first 16 bits work like xAPIC flat logical mode. >> >> Ok, I was

Re: [PATCH v8 03/13] KVM: Define a new interface kvm_intr_is_single_vcpu()

On 18/09/2015 18:16, Radim Krčmář wrote: >>> >> Ok, I was wondering whether this was the correct interpretation. Thanks! >> > >> > Paolo, I don't think Radim clarify your concern, right? Since mda is >> > 8-bit, it >> > is wrong with mda >> 16, this is your concern, right? > In case it was:

Re: [PATCH v9 00/18] Add VT-d Posted-Interrupts support - including prerequisite series

On 18/09/2015 17:08, Wu, Feng wrote: > > >> -Original Message- >> From: Paolo Bonzini [mailto:pbonz...@redhat.com] >> Sent: Friday, September 18, 2015 10:59 PM >> To: Wu, Feng; alex.william...@redhat.com; j...@8bytes.org; >> mtosa...@redhat.com >> Cc: eric.au...@linaro.org;

Re: rdmsr_safe in Linux PV (under Xen) gets an #GP:Re: [Fedora-xen] Running fedora xen on top of KVM?

On Fri, Sep 18, 2015 at 6:54 AM, Borislav Petkov wrote: > On Thu, Sep 17, 2015 at 01:23:31PM -0700, Andy Lutomirski wrote: >> Cc: Borislav. Is TSEG guaranteed to exist? Can we defer that until > > Why not? It is the tseg base address. > > I think this is kvm injecting a #GP as

RE: [PATCH v9 01/18] virt: IRQ bypass manager

Signed-off-by: Feng Wu > -Original Message- > From: iommu-boun...@lists.linux-foundation.org > [mailto:iommu-boun...@lists.linux-foundation.org] On Behalf Of Feng Wu > Sent: Friday, September 18, 2015 10:30 PM > To: pbonz...@redhat.com; alex.william...@redhat.com;

[PATCH] KVM: x86: trap AMD MSRs for the TSeg base and mask

These have roughly the same purpose as the SMRR, which we do not need to implement in KVM. However, Linux accesses MSR_K8_TSEG_ADDR at boot, which causes problems when running a Xen dom0 under KVM. Just return 0, meaning that processor protection of SMRAM is not in effect. Signed-off-by: Paolo

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,

[PATCH 2/2] Revert "KVM: x86: zero kvmclock_offset when vcpu0 initializes kvmclock system MSR"

Shifting pvclock_vcpu_time_info.system_time on write to KVM system time MSR is a change of ABI. Probably only 2.6.16 based SLES 10 breaks due to its custom enhancements to kvmclock, but KVM never declared the MSR only for one-shot initialization. (Doc says that only one write is needed.) This

[PATCH 1/2] x86: kvmclock: abolish PVCLOCK_COUNTS_FROM_ZERO

Newer KVM won't be exposing PVCLOCK_COUNTS_FROM_ZERO anymore. The purpose of that flags was to start counting system time from 0 when the KVM clock has been initialized. We can achieve the same by selecting one read as the initial point. A simple subtraction will work unless the KVM clock count

[RFC PATCH 0/2] kvmclock: fix ABI breakage from PVCLOCK_COUNTS_FROM_ZERO.

This patch series will be disabling PVCLOCK_COUNTS_FROM_ZERO flag and is RFC because I haven't explored many potential problems or tested it. [1/2] uses a different algorithm in the guest to start counting from 0. [2/2] stops exposing PVCLOCK_COUNTS_FROM_ZERO in the hypervisor. A viable

Re: [PATCH] kvmtool: don't rely on $HOME

On 18 September 2015 at 13:56, Will Deacon wrote: > On Fri, Sep 18, 2015 at 11:51:37AM +0100, Riku Voipio wrote: >> On 17 September 2015 at 18:53, Will Deacon wrote: >> > On Thu, Sep 17, 2015 at 03:03:15PM +0100, Alban Crequy wrote: >> >> kvm__set_dir()

Re: [PATCH v9 17/18] KVM: Update Posted-Interrupts Descriptor when vCPU is blocked

On 18/09/2015 16:29, Feng Wu wrote: > This patch updates the Posted-Interrupts Descriptor when vCPU > is blocked. > > pre-block: > - Add the vCPU to the blocked per-CPU list > - Set 'NV' to POSTED_INTR_WAKEUP_VECTOR > > post-block: > - Remove the vCPU from the per-CPU list > > Signed-off-by:

[PATCH] irq_remapping: move structs outside #ifdef

This is friendlier to clients of the code, who are going to prepare vcpu_data structs unconditionally, even if CONFIG_IRQ_REMAP is not defined. Signed-off-by: Paolo Bonzini --- Please ack, I'd like to include it in the 4.4 pull request.

Re: rdmsr_safe in Linux PV (under Xen) gets an #GP:Re: [Fedora-xen] Running fedora xen on top of KVM?

On 18/09/2015 15:54, Borislav Petkov wrote: > On Thu, Sep 17, 2015 at 01:23:31PM -0700, Andy Lutomirski wrote: >> > Cc: Borislav. Is TSEG guaranteed to exist? Can we defer that until > Why not? It is the tseg base address. > > I think this is kvm injecting a #GP as it is not ignoring this

RE: [PATCH v9 04/18] KVM: create kvm_irqfd.h

Signed-off-by: Feng Wu > -Original Message- > From: iommu-boun...@lists.linux-foundation.org > [mailto:iommu-boun...@lists.linux-foundation.org] On Behalf Of Feng Wu > Sent: Friday, September 18, 2015 10:30 PM > To: pbonz...@redhat.com; alex.william...@redhat.com;

RE: [PATCH v9 00/18] Add VT-d Posted-Interrupts support - including prerequisite series

> -Original Message- > From: Paolo Bonzini [mailto:pbonz...@redhat.com] > Sent: Friday, September 18, 2015 11:21 PM > To: Wu, Feng; alex.william...@redhat.com; j...@8bytes.org; > mtosa...@redhat.com > Cc: eric.au...@linaro.org; kvm@vger.kernel.org; > io...@lists.linux-foundation.org;

Re: [PATCH v9 12/18] vfio: Register/unregister irq_bypass_producer

On Fri, 2015-09-18 at 22:29 +0800, Feng Wu wrote: > This patch adds the registration/unregistration of an > irq_bypass_producer for MSI/MSIx on vfio pci devices. > > Signed-off-by: Feng Wu On nit, Paolo could you please fix the spelling of "registration" in the dev_info,

[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,