Re: MCG_CAP ABI breakage (was Re: [Qemu-devel] [PATCH] target-i386: Do not set MCG_SER_P by default)

On Mon, Nov 23, 2015 at 05:43:14PM +0100, Borislav Petkov wrote: > On Mon, Nov 23, 2015 at 01:11:27PM -0200, Eduardo Habkost wrote: > > On Mon, Nov 23, 2015 at 11:22:37AM -0200, Eduardo Habkost wrote: > > [...] > > > In the case of this code, it looks like it's already broken > > > because the

[Bug 107561] 4.2 breaks PCI passthrough in QEMU/KVM

https://bugzilla.kernel.org/show_bug.cgi?id=107561 --- Comment #8 from schefis...@gmail.com --- I captured the traces, they take more than half a GB uncompressed. They are available in xz under https://drive.google.com/folderview?id=0B8ebX_WjVHnGNlN4eTEzU2xtMEk=sharing To make things clear: I

Re: [PATCH 05/21] arm64: KVM: Implement timer save/restore

On Mon, Nov 16, 2015 at 01:11:43PM +, Marc Zyngier wrote: > Implement the timer save restore as a direct translation of > the assembly code version. Hi Marc, some comments below. Cheers, -- Steve > > Signed-off-by: Marc Zyngier > --- > arch/arm64/kvm/hyp/Makefile

[PATCH 2/2] KVM: Create debugfs dir and stat files for each VM

From: Janosch Frank KVM statistics for VMs (no. of exits, halts and other special instructions) are currently only available in a summarized manner for all VMs. They are exported to userland through files in the kvm debugfs directory and used for performance

[PATCH v2 0/2] RFC: kvm stat enhancements

Paolo, here is an updated version of the kvm_stat enhancements. (containing the fixes from Dan Carpenter) I am preparing a pull request for s390 and I could add these patches into the pull request. Shall I defer these patches until further review, or are we confident enough to add them to queue

[PATCH 1/2] KVM: Remove unnecessary debugfs dentry references

From: Janosch Frank KVM creates debugfs files to export VM statistics to userland. To be able to remove them on kvm exit it tracks the files' dentries. Since their parent directory is also tracked and since each parent direntry knows its children we can easily remove

Re: [Qemu-devel] [PATCH v8 0/5] implement vNVDIMM

On Thu, Nov 19, 2015 at 10:39:05AM +0800, Xiao Guangrong wrote: > On 11/19/2015 04:44 AM, Michael S. Tsirkin wrote: > >On Wed, Nov 18, 2015 at 05:18:17PM -0200, Eduardo Habkost wrote: > >>On Wed, Nov 18, 2015 at 09:59:34AM +0800, Xiao Guangrong wrote: > >sorry, I'm busy with 2.5 now, and this is

RE: LAST WARNING FROM ADMIN

From: Salih, Elyas Sent: 23 November 2015 09:23 To: Salih, Elyas Subject: LAST WARNING FROM ADMIN Dear E-mail User:- Take note of this important update that our new web mail has been improved with a new messaging system from Owa/outlook which also include

Re: [PATCH] target-i386: Do not set MCG_SER_P by default

On Sat, Nov 21, 2015 at 02:09:25AM +0100, Borislav Petkov wrote: > On Sat, Nov 21, 2015 at 12:11:35AM +0100, Andreas Färber wrote: > > Hi, > > > > CC'ing qemu-devel. > > Ah, thanks. > > > Am 21.11.2015 um 00:01 schrieb Borislav Petkov: > > > From: Borislav Petkov > > > > > >

Re: [PATCH] target-i386: Do not set MCG_SER_P by default

On 23/11/2015 14:22, Eduardo Habkost wrote: > > Software Error Recovery, i.e. SER, is purely an Intel feature and it > > shouldn't be set by default. Enable it only on Intel. > > What happens when SER is enabled on an AMD CPU? If it really > should't be enabled, why is KVM returning it on >

RE: [PATCH] KVM: x86: Add lowest-priority support for vt-d posted-interrupts

> -Original Message- > From: Paolo Bonzini [mailto:pbonz...@redhat.com] > Sent: Tuesday, November 17, 2015 5:41 PM > To: Radim Krčmář ; Wu, Feng > Cc: kvm@vger.kernel.org; linux-ker...@vger.kernel.org > Subject: Re: [PATCH] KVM: x86: Add

RE: [PATCH] KVM: x86: Add lowest-priority support for vt-d posted-interrupts

> -Original Message- > From: Radim Krčmář [mailto:rkrc...@redhat.com] > Sent: Tuesday, November 17, 2015 3:03 AM > To: Wu, Feng > Cc: pbonz...@redhat.com; kvm@vger.kernel.org; linux- > ker...@vger.kernel.org > Subject: Re: [PATCH] KVM: x86: Add lowest-priority support

[Bug 108381] New: KVM crashes when using qemu/kvm with specific BIOS

https://bugzilla.kernel.org/show_bug.cgi?id=108381 Bug ID: 108381 Summary: KVM crashes when using qemu/kvm with specific BIOS Product: Virtualization Version: unspecified Kernel Version: 4.2.5 Hardware: x86-64 OS: Linux

[PATCH v6 3/3] target-i386: add support to migrate vcpu's TSC rate

This patch enables migrating vcpu's TSC rate. If KVM on the destination machine supports TSC scaling, guest programs will observe a consistent TSC rate across the migration. If TSC scaling is not supported on the destination machine, the migration will not be aborted and QEMU on the destination

[PATCH v6 2/3] target-i386: reorganize TSC rate setting code

Following changes are made to the TSC rate setting code in kvm_arch_init_vcpu(): * The code is moved to a new function kvm_arch_set_tsc_khz(). * If kvm_arch_set_tsc_khz() fails, i.e. following two conditions are both satisfied: * KVM does not support the TSC scaling or it fails to set

[PATCH v6 1/3] target-i386: fallback vcpu's TSC rate to value returned by KVM

If no user-specified TSC rate is present, we will try to set env->tsc_khz to the value returned by KVM_GET_TSC_KHZ. This patch does not change the current functionality of QEMU and just prepares for later patches to enable migrating vcpu's TSC rate. Signed-off-by: Haozhong Zhang

[PATCH v6 0/3] target-i386: save/restore vcpu's TSC rate during migration

This patchset enables QEMU to save/restore vcpu's TSC rate during the migration on machine types pc-*-2.5 or newer. On the source machine: * If the vcpu's TSC rate is specified by the cpu option 'tsc-freq', then this user-specified TSC rate will be migrated. * Otherwise, the TSC rate

[PATCH 2/3] gicv3, its: Introduce VFIO map and unmap operations

These new functions use the supplied IOMMU in order to map and unmap MSI translation register(s). Signed-off-by: Pavel Fedin --- drivers/irqchip/irq-gic-v3-its.c | 31 +++ include/linux/irqchip/arm-gic-v3.h | 2 ++ include/linux/msi.h

[PATCH 1/3] vfio: Introduce map and unmap operations

These new functions allow direct mapping and unmapping of addresses on the given IOMMU. They will be used for mapping MSI hardware. Signed-off-by: Pavel Fedin --- drivers/vfio/vfio_iommu_type1.c | 29 + include/linux/vfio.h| 4 +++-

[PATCH 0/3] Introduce MSI hardware mapping for VFIO

On some architectures (e.g. ARM64) if the device is behind an IOMMU, and is being mapped by VFIO, it is necessary to also add mappings for MSI translation register for interrupts to work. This series implements the necessary API to do this, and makes use of this API for GICv3 ITS on ARM64. Pavel

MCG_CAP ABI breakage (was Re: [Qemu-devel] [PATCH] target-i386: Do not set MCG_SER_P by default)

On Mon, Nov 23, 2015 at 11:22:37AM -0200, Eduardo Habkost wrote: [...] > In the case of this code, it looks like it's already broken > because the resulting mcg_cap depends on host kernel capabilities > (the ones reported by kvm_get_mce_cap_supported()), and the data > initialized by

Re: MCG_CAP ABI breakage (was Re: [Qemu-devel] [PATCH] target-i386: Do not set MCG_SER_P by default)

On Mon, Nov 23, 2015 at 01:11:27PM -0200, Eduardo Habkost wrote: > On Mon, Nov 23, 2015 at 11:22:37AM -0200, Eduardo Habkost wrote: > [...] > > In the case of this code, it looks like it's already broken > > because the resulting mcg_cap depends on host kernel capabilities > > (the ones reported

Trying to switch EPTP for execute-protecting guest pages

Hi all, I'm playing around with EPTs and kvm to track execution in the guest. I've created a separate set of EPTs (and copied the last level entries from the real tables, minus execute permissions) but I'm not getting exits where I expect. I also have code in handle_ept_violation to preserve

Re: [PATCH] target-i386: Do not set MCG_SER_P by default

+ Tony. On Mon, Nov 23, 2015 at 03:47:44PM +0100, Paolo Bonzini wrote: > On 23/11/2015 14:22, Eduardo Habkost wrote: > > > Software Error Recovery, i.e. SER, is purely an Intel feature and it > > > shouldn't be set by default. Enable it only on Intel. > > > > What happens when SER is enabled on

Re: [PATCH] virtio_ring: Shadow available ring flags & index

On 11/21/2015 2:30 AM, Venkatesh Srinivas wrote: > On Thu, Nov 19, 2015 at 04:15:48PM +, Xie, Huawei wrote: >> On 11/18/2015 12:28 PM, Venkatesh Srinivas wrote: >>> On Tue, Nov 17, 2015 at 08:08:18PM -0800, Venkatesh Srinivas wrote: On Mon, Nov 16, 2015 at 7:46 PM, Xie, Huawei

Re: MCG_CAP ABI breakage (was Re: [Qemu-devel] [PATCH] target-i386: Do not set MCG_SER_P by default)

On Mon, Nov 23, 2015 at 05:42:08PM -0200, Eduardo Habkost wrote: > I will let the people working on the actual MCE emulation in KVM > answer that. I am assuming that KVM_MCE_CAP_SUPPORTED is set to > something that makes sense. Well, that should be, IMHO, the same like all those feature bits

[RFC PATCH 3/3] vfio/pci: Include sparse mmap capability for MSI-X table regions

vfio-pci has never allowed the user to directly mmap the MSI-X vector table, but we've always relied on implicit knowledge of the user that they cannot do this. Now that we have capability chains that we can expose in the region info ioctl and a sparse mmap capability that represents the

[RFC PATCH 0/3] VFIO: capability chains

Please see the commit log and comments in patch 1 for a general explanation of the problems that this series tries to address. The general problem is that we have several cases where we want to expose variable sized information to the user, whether it's sparse mmaps for a region, as implemented

[RFC PATCH 2/3] vfio: Define sparse mmap capability for regions

We can't always support mmap across an entire device region, for example we deny mmaps covering the MSI-X table of PCI devices, but we don't really have a way to report it. We expect the user to implicitly know this restriction. We also can't split the region because vfio-pci defines an API with

[RFC PATCH 1/3] vfio: Define capability chains

We have a few cases where we need to extend the data returned from the INFO ioctls in VFIO. For instance we already have devices exposed through vfio-pci where VFIO_DEVICE_GET_REGION_INFO reports the region as mmap-capable, but really only supports sparse mmaps, avoiding the MSI-X table. If we

[RFC post-2.5 PATCH 2/5] vfio: Generalize region support

Both platform and PCI vfio drivers create a "slow", I/O memory region with one or more mmap memory regions overlayed when supported by the device. Generalize this to a set of common helpers in the core that pulls the region info from vfio, fills the region data, configures slow mapping, and adds

[RFC post-2.5 PATCH 1/5] vfio: Wrap VFIO_DEVICE_GET_REGION_INFO

In preparation for supporting capability chains on regions, wrap ioctl(VFIO_DEVICE_GET_REGION_INFO) so we don't duplicate the code for each caller. Signed-off-by: Alex Williamson --- hw/vfio/common.c | 18 + hw/vfio/pci.c | 81

[RFC post-2.5 PATCH 4/5] linux-headers/vfio: Update for proposed capabilities list

Signed-off-by: Alex Williamson --- linux-headers/linux/vfio.h | 53 +++- 1 file changed, 52 insertions(+), 1 deletion(-) diff --git a/linux-headers/linux/vfio.h b/linux-headers/linux/vfio.h index aa276bc..c3860f6 100644 ---

[RFC post-2.5 PATCH 3/5] vfio/pci: Convert all MemoryRegion to dynamic alloc and consistent functions

Match common vfio code with setup, exit, and finalize functions for BAR, quirk, and VGA management. VGA is also changed to dynamic allocation to match the other MemoryRegions. Signed-off-by: Alex Williamson --- hw/vfio/pci-quirks.c | 38 -

[RFC post-2.5 PATCH 0/5] VFIO: capability chains

This is the matching QEMU changes for the proposed kernel-side capability chains. Unfortunately there's also a lot of churn to get to consistent interfaces involved in this series, which allow us to generically handle multiple mmaps overlapping a region and making the actual step of consuming the

[RFC post-2.5 PATCH 5/5] vfio: Enable sparse mmap capability

The sparse mmap capability in a vfio region info allows vfio to tell us which sub-areas of a region may be mmap'd. Thus rather than assuming a single mmap covers the entire region and later frobbing it ourselves for things like the PCI MSI-X vector table, we can read that directly from vfio.