Re: [PATCH] KVM: svm: add support for RDTSCP

MSR_TSC_AUX while running the guest. > > Cc: Joerg Roedel <j...@8bytes.org> > Signed-off-by: Paolo Bonzini <pbonz...@redhat.com> > --- > arch/x86/kvm/svm.c | 24 +++- > 1 file changed, 23 insertions(+), 1 deletion(-) > > diff --git a/arch/x8

Re: [PATCH v4 0/6] virtio core DMA API conversion

On Tue, Nov 10, 2015 at 01:04:36PM +1100, Benjamin Herrenschmidt wrote: > The "in absence of the new DT binding" doesn't make that much sense. > > Those platforms use device-trees defined since the dawn of ages by > actual open firmware implementations, they either have no iommu > representation

Re: [PATCH v3 0/3] virtio DMA API core stuff

On Sun, Nov 08, 2015 at 12:37:47PM +0200, Michael S. Tsirkin wrote: > I have no problem with that. For example, can we teach > the DMA API on intel x86 to use PT for virtio by default? > That would allow merging Andy's patches with > full compatibility with old guests and hosts. Well, the only

Re: [PATCH v1 2/2] dma-mapping-common: add DMA attribute - DMA_ATTR_IOMMU_BYPASS

On Mon, Nov 02, 2015 at 07:32:19PM +0200, Shamir Rabinovitch wrote: > Correct. This issue is one of the concerns here in the previous replies. > I will take different approach which will not require the IOMMU bypass > per mapping. Will try to shift to the x86 'iommu=pt' approach. Yeah, it doesn't

Re: [PATCH 1/3] dma: Provide simple noop dma ops

f-by: Christian Borntraeger <borntrae...@de.ibm.com> > --- > include/linux/dma-mapping.h | 2 ++ > lib/Makefile| 1 + > lib/dma-noop.c | 75 > + > 3 files changed, 78 insertions(+) > create mode 100644

[PATCH] vfio: Fix bug in vfio_device_get_from_name()

From: Joerg Roedel <jroe...@suse.de> The vfio_device_get_from_name() function might return a non-NULL pointer, when called with a device name that is not found in the list. This causes undefined behavior, in my case calling an invalid function pointer later on: kernel tried to exec

Re: [PATCH 1/3] Provide simple noop dma ops

On Fri, Oct 30, 2015 at 02:20:35PM +0100, Christian Borntraeger wrote: > +static void *dma_noop_alloc(struct device *dev, size_t size, > + dma_addr_t *dma_handle, gfp_t gfp, > + struct dma_attrs *attrs) > +{ > + void *ret; > + > + ret = (void

Re: [PATCH 2/3] alpha: use common noop dma ops

a/kernel/pci-noop.c | 46 > > 1 file changed, 4 insertions(+), 42 deletions(-) Reviewed-by: Joerg Roedel <jroe...@suse.de> -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 2/2] dma-mapping-common: add DMA attribute - DMA_ATTR_IOMMU_BYPASS

On Thu, Oct 29, 2015 at 09:32:32AM +0200, Shamir Rabinovitch wrote: > For the IB case, setting and tearing DMA mappings for the drivers data buffers > is expensive. But we could for example consider to map all the HW control > objects > that validate the HW access to the drivers data buffers as

Re: [PATCH 3/3] s390/dma: Allow per device dma ops

h/s390/include/asm/device.h | 6 +- > arch/s390/include/asm/dma-mapping.h | 6 -- > arch/s390/pci/pci.c | 1 + > arch/s390/pci/pci_dma.c | 4 ++-- > 5 files changed, 14 insertions(+), 6 deletions(-) Reviewed-by: Joerg Roedel <jroe...@suse.de> -- To

Re: [PATCH v1 2/2] dma-mapping-common: add DMA attribute - DMA_ATTR_IOMMU_BYPASS

On Fri, Oct 30, 2015 at 11:32:06AM +0100, Arnd Bergmann wrote: > I wonder if the 'iommu=force' attribute is too coarse-grained though, > and if we should perhaps allow a per-device setting on architectures > that allow this. Yeah, definitly. Currently we only have iommu=pt to enable pass-through

Re: [PATCH 1/4] Provide simple noop dma ops

On Fri, Oct 30, 2015 at 01:55:56PM +0100, Christian Borntraeger wrote: > It not trivial without understanding the dma mask details. Do I read > the x86 implementation right, that it limits the dma to 32 bit? Then > we cannot collapse both implementations. Or maybe we can hide this in >

Re: [PATCH v3 0/3] virtio DMA API core stuff

On Thu, Oct 29, 2015 at 11:01:41AM +0200, Michael S. Tsirkin wrote: > Example: you have a mix of assigned devices and virtio devices. You > don't trust your assigned device vendor not to corrupt your memory so > you want to limit the damage your assigned device can do to your guest, > so you use

Re: [PATCH 1/4] Provide simple noop dma ops

Hi Christian, On Tue, Oct 27, 2015 at 11:48:48PM +0100, Christian Borntraeger wrote: > +static dma_addr_t dma_noop_map_page(struct device *dev, struct page *page, > + unsigned long offset, size_t size, > + enum dma_data_direction

Re: [PATCH/RFC 0/4] dma ops and virtio

Hi Christian, On Tue, Oct 27, 2015 at 11:48:47PM +0100, Christian Borntraeger wrote: > Here is a very quick (still untested) shot at providing the s390 part: > - patch1: dummy dma ops, inspired by the alpha code > - patch2: replace some of the alpha functions with the dummy ones > - patch3: allow

Re: [PATCH 4/4] s390/virtio: use noop dma ops

On Tue, Oct 27, 2015 at 11:48:51PM +0100, Christian Borntraeger wrote: > @@ -1093,6 +1094,7 @@ static void virtio_ccw_auto_online(void *data, > async_cookie_t cookie) > struct ccw_device *cdev = data; > int ret; > > + cdev->dev.archdata.dma_ops = _noop_ops; > ret =

Re: [PATCH 2/3] virtio_ring: Support DMA APIs

Hi Andy, On Tue, Oct 27, 2015 at 06:17:09PM -0700, Andy Lutomirski wrote: > From: Andy Lutomirski > > virtio_ring currently sends the device (usually a hypervisor) > physical addresses of its I/O buffers. This is okay when DMA > addresses and physical addresses are the

Re: [PATCH 1/3] virtio_net: Stop doing DMA from the stack

- > 1 file changed, 36 insertions(+), 17 deletions(-) Reviewed-by: Joerg Roedel <jroe...@suse.de> -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/3] virtio_pci: Use the DMA API

On Tue, Oct 27, 2015 at 06:17:10PM -0700, Andy Lutomirski wrote: > From: Andy Lutomirski > > This fixes virtio-pci on platforms and busses that have IOMMUs. This > will break the experimental QEMU Q35 IOMMU support until QEMU is > fixed. In exchange, it fixes physical

Re: [PATCH 2/3] virtio_ring: Support DMA APIs

On Tue, Oct 27, 2015 at 07:13:56PM -0700, Andy Lutomirski wrote: > On Tue, Oct 27, 2015 at 7:06 PM, Joerg Roedel <jroe...@suse.de> wrote: > > Hi Andy, > > > > On Tue, Oct 27, 2015 at 06:17:09PM -0700, Andy Lutomirski wrote: > >> From: Andy Lutomirski <l..

Re: [PATCH 3/3] virtio_pci: Use the DMA API

On Wed, Oct 28, 2015 at 11:15:30AM +0900, Joerg Roedel wrote: > Same here, you need to call the dma_sync* functions when passing data > from/to the virtio-device. Okay, forget about this comment. This patch only converts to dma_coherent allocations, which don't need synchronization. >

Re: [PATCH 3/3] virtio_pci: Use the DMA API

On Wed, Oct 28, 2015 at 11:22:52AM +0900, David Woodhouse wrote: > On Wed, 2015-10-28 at 11:15 +0900, Joerg Roedel wrote: > > I think a good test for that is to boot a virtio kvm-guest with > > swiotlb=force and see if it still works. > > That's useful but doesn't cover th

Re: [PATCH v2 00/12] KVM: x86: add support for VMX TSC scaling

On Tue, Oct 20, 2015 at 03:39:00PM +0800, Haozhong Zhang wrote: > VMX TSC scaling shares some common logics with SVM TSC ratio which > is already supported by KVM. Patch 1 ~ 8 move those common logics from > SVM code to the common code. Upon them, patch 9 ~ 12 add VMX-specific > support for VMX

Re: [PATCH v2 00/12] KVM: x86: add support for VMX TSC scaling

On Fri, Oct 23, 2015 at 08:32:28PM +0800, Haozhong Zhang wrote: > No, since I don't have AMD machines at hand. The modifications to SVM > code are mostly lifting common code with VMX TSC scaling code, so it > should still work on AMD machines. Well, I think it would be good if you can provide a

[PATCH v2] kvm: svm: Only propagate next_rip when guest supports it

>From 94ee662c527683c26ea5fa98a5a8f2c798c58470 Mon Sep 17 00:00:00 2001 From: Joerg Roedel <jroe...@suse.de> Date: Wed, 7 Oct 2015 13:38:19 +0200 Subject: [PATCH] kvm: svm: Only propagate next_rip when guest supports it Currently we always write the next_rip of the shadow vmcb to the guests vmcb when we e

[PATCH] kvm: svm: Only propagate next_rip when guest supports it

From: Joerg Roedel <jroe...@suse.de> Currently we always write the next_rip of the shadow vmcb to the guests vmcb when we emulate a vmexit. This could confuse the guest when its cpuid indicated no support for the next_rip feature. Fix this by only propagating next_rip if the guest ac

BUG: unable to handle kernel paging request with v4.3-rc4

Hi Alex, while playing around with attaching a 32bit PCI device to a guest via VFIO I triggered this oops: [ 192.289917] kernel tried to execute NX-protected page - exploit attempt? (uid: 0) [ 192.298245] BUG: unable to handle kernel paging request at 880224582608 [ 192.306195] IP: []

Re: BUG: unable to handle kernel paging request with v4.3-rc4

On Fri, Oct 09, 2015 at 09:30:40AM -0600, Alex Williamson wrote: > I have not seen this one yet. There literally have been no changes for > vfio in 4.3, so if this is new, it may be collateral from changes > elsewhere. 32bit devices really shouldn't make any difference to vfio, > I'll see if I

Re: [PATCH] Use WARN_ON_ONCE for missing X86_FEATURE_NRIPS

On Tue, Oct 06, 2015 at 01:59:27PM -0400, Bandan Das wrote: > Joerg Roedel <j...@8bytes.org> writes: > > > > So svm->vmcb->control.next_rip is only written by hardware or in > > svm_check_intercept(). Both cases write only to this field, if the > > hardwar

[PATCH] kvm: svm: Only propagate next_rip when guest supports it

On Wed, Oct 07, 2015 at 01:03:35PM +0200, Joerg Roedel wrote: > But we don't care if L1 writes something into its own next_rip, as we > never read this value from its VMCB. We only copy the next_rip value we > get from our shadow-vmcb to it on an emulated vmexit. So I still don't > und

Re: [PATCH] Use WARN_ON_ONCE for missing X86_FEATURE_NRIPS

On Wed, Oct 07, 2015 at 10:58:07AM -0400, Bandan Das wrote: > Ok, looks like I am making some incorrect "vmx" assumptions here. What happens > when we exit from L2 to L0, arent' we looking at the VMCB L1 is using to run > L2 ? Wouldn't that trigger the warning if the host processor does not

Re: [PATCH] kvm: svm: Only propagate next_rip when guest supports it

On Wed, Oct 07, 2015 at 11:48:36AM -0400, Bandan Das wrote: > Ok, understood now. The warn_on would trigger in L1 only if it has > decided to disable nrips for some reason as was the case here. So, > my reasoning behind putting the warning was incorrect. Okay, so I think the warning can be

Re: [PATCH] iommu/s390: add iommu api for s390 pci devices

On Thu, Oct 01, 2015 at 07:30:28PM +0200, Gerald Schaefer wrote: > Yes, the DMA API is already implemented in arch/s390/pci/pci_dma.c. > I thought about moving it over to the new location in drivers/iommu/, > but I don't see any benefit from it. Okay, this is true for now. At some point we

Re: [PATCH] iommu/s390: add iommu api for s390 pci devices

On Thu, Aug 27, 2015 at 03:33:03PM +0200, Gerald Schaefer wrote: > This adds an IOMMU API implementation for s390 PCI devices. > > Reviewed-by: Sebastian Ott > Signed-off-by: Gerald Schaefer > --- > MAINTAINERS | 7 +

Re: [PATCH] Use WARN_ON_ONCE for missing X86_FEATURE_NRIPS

On Mon, Oct 05, 2015 at 01:42:43PM -0400, Bandan Das wrote: > Joerg Roedel <j...@8bytes.org> writes: > > > On Mon, Oct 05, 2015 at 12:54:43PM -0400, Bandan Das wrote: > >> Joerg Roedel <j...@8bytes.org> writes: > >> The problems is that the next_

Re: [PATCH] Use WARN_ON_ONCE for missing X86_FEATURE_NRIPS

On Thu, Oct 01, 2015 at 06:31:27PM -0400, Bandan Das wrote: > >> @@ -514,7 +514,7 @@ static void skip_emulated_instruction(struct kvm_vcpu > >> *vcpu) > >>struct vcpu_svm *svm = to_svm(vcpu); > >> > >>if (svm->vmcb->control.next_rip != 0) { > >> -

Re: [PATCH] Use WARN_ON_ONCE for missing X86_FEATURE_NRIPS

On Thu, Oct 01, 2015 at 06:31:27PM -0400, Bandan Das wrote: > Paolo Bonzini writes: > > > On 01/10/2015 13:43, Dirk Müller wrote: > >> diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c > >> index 94b7d15..0a42859 100644 > >> --- a/arch/x86/kvm/svm.c > >> +++

Re: [PATCH] Use WARN_ON_ONCE for missing X86_FEATURE_NRIPS

On Mon, Oct 05, 2015 at 12:54:43PM -0400, Bandan Das wrote: > Joerg Roedel <j...@8bytes.org> writes: > The problems is that the next_rip field could be stale. If the processor > supports > next_rip, then it will clear it out on the next entry. If it doesn't, > a

Re: [PATCH] iommu/s390: add iommu api for s390 pci devices

Hi Gerald, thanks for your patch. It looks pretty good and addresses my previous review comments. I have a few questions, first one is how this operates with DMA-API on s390. Is there a seperate DMA-API implementation besides the IOMMU-API one for PCI devices? My other question is inline: On

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

-parameters.txt | 1 + > drivers/iommu/irq_remapping.c | 12 > 2 files changed, 9 insertions(+), 4 deletions(-) Acked-by: Joerg Roedel <jroe...@suse.de> -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to

Re: [RTF] kvm:x86:Fix error checking in the function pf_interception

On Thu, Aug 06, 2015 at 10:10:23PM -0400, Nicholas Krause wrote: This fixes error checking in the function pf_interception by checking if the call to kvm_mmu_unprotect_page_virt returns zero to indicate the function has failed internally and if this occurs we must return immediately to the

Re: [RFC PATCH 0/1] iommu: Detach device from domain when removed from group

On Tue, Jul 28, 2015 at 07:55:55PM +0200, Gerald Schaefer wrote: On s390, this eventually leads to a kernel panic when binding the device again to its non-vfio PCI driver, because of the missing arch-specific cleanup in detach_dev. On x86, the detach_dev callback will also not be called

Re: Lockdep warning in VFIO using v4.2-rc3

for your quick look. Tested-by: Joerg Roedel jroe...@suse.de -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Lockdep warning in VFIO using v4.2-rc3

Hi Alex, I stumbled over this lockdep warning yesterday while testing my VT-d changes. It looks like one code path is taking the locks: group-device_lock driver_lock pci_bus_sem while another path is taking pci_bus_sem group-device_lock which could lead

Re: [PATCH] KVM: svm: remove KVM_QUIRK_CD_NW_CLEARED quirk

--- arch/x86/kvm/svm.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) Looks good to me. Reviewed-by: Joerg Roedel jroe...@suse.de -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info

Re: [RFC v2 0/6] IRQ bypass manager and irqfd consumer

On Thu, Jul 09, 2015 at 04:38:41PM +0200, Paolo Bonzini wrote: On Tue, Jul 07, 2015 at 11:17:48AM -0600, Alex Williamson wrote: If we think that it's *only* a kvm-vfio interaction then we could add it to virt/kvm/vfio.c. vfio could use symbol_get to avoid a module dependency and

Re: [RFC v2 0/6] IRQ bypass manager and irqfd consumer

On Tue, Jul 07, 2015 at 11:17:48AM -0600, Alex Williamson wrote: Hosting the bypass manager in kernel/irq seemed appropriate, but really it could be anywhere. Does anyone have a different preference or specifically want it under their scope? We had originally thought of this as an IOMMU

Re: [RFC/RFT PATCH v3 0/4] KVM: x86: full virtualization of guest MTRR

On Wed, Jul 08, 2015 at 05:18:26PM +0200, Paolo Bonzini wrote: I do not have any AMD machines that support an IOMMU, so I would like some help testing these patches. Works here, tested on an AMD IOMMUv2 machine and could successfully download a file over the assigned NIC. Tested-by: Joerg

Re: [RFC/RFT PATCH v2 0/4] KVM: x86: full virtualization of guest MTRR

On Tue, Jul 07, 2015 at 04:09:07PM +0200, Paolo Bonzini wrote: The guest should not take ages to boot, which is typical of messed-up MTRR/PAT. And if you add some actual usage of the attached device, it actually is sufficient. Even a simple ping test, or typing through a USB keyboard on a

Re: [RFC/RFT PATCH v2 0/4] KVM: x86: full virtualization of guest MTRR

Hi Paolo, On Tue, Jul 07, 2015 at 03:45:35PM +0200, Paolo Bonzini wrote: I do not have any AMD machines that support an IOMMU, so I would like some help testing these patches. Thanks, What kind of testing do you want? Booting a guest with a device attached is probably not sufficient, right?

Re: [PATCH 1/3] KVM: SVM: use NPT page attributes

Hi Paolo, On Tue, Jul 07, 2015 at 02:58:12PM +0200, Paolo Bonzini wrote: +static void svm_set_guest_pat(struct vcpu_svm *svm, u64 *g_pat) +{ + struct kvm_vcpu *vcpu = svm-vcpu; + + /* Unlike Intel, AMD takes the guest's CR0.CD into account. + * + * AMD doesn't have

Re: [v4 08/16] KVM: kvm-vfio: User API for IRQ forwarding

On Mon, Jun 29, 2015 at 09:14:54AM +, Wu, Feng wrote: Do you mean updating the hardware IRTEs for all the entries in the irq routing table, no matter whether it is the updated one? Right, that's what I mean. It seems wrong to me to work around the API interface by creating a diff between

Re: [v4 08/16] KVM: kvm-vfio: User API for IRQ forwarding

Hi Feng, On Thu, Jun 25, 2015 at 09:11:52AM -0600, Alex Williamson wrote: So the trouble is that QEMU vfio updates a single MSI vector, but that just updates a single entry within a whole table of routes, then the whole table is pushed to KVM. But in kvm_set_irq_routing() we have access to

[PATCH] kvm: irqchip: Fix possible memory leak in kvm_set_irq_routing()

2001 From: Joerg Roedel jroe...@suse.de Date: Fri, 26 Jun 2015 18:02:47 +0200 Subject: [PATCH] kvm: irqchip: Fix possible memory leak in kvm_set_irq_routing() If ue-flags field is checked after the allocation of the kvm_kernel_irq_routing_entry, it will be leaked if the check succeeds. Do

Re: [v4 08/16] KVM: kvm-vfio: User API for IRQ forwarding

On Mon, Jun 15, 2015 at 06:17:03PM +0200, Eric Auger wrote: I guess this discussion also is relevant wrt [RFC v6 00/16] KVM-VFIO IRQ forward control series? Or is that central registry maintained by a posted interrupts manager something more specific to x86? From what I understood so far, the

Re: [v4 08/16] KVM: kvm-vfio: User API for IRQ forwarding

On Thu, Jun 18, 2015 at 02:04:08PM -0600, Alex Williamson wrote: There are plenty of details to be filled in, I also need to fill plenty of details in my head first, so here are some suggestions based on my current understanding. Please don't hesitate to correct me if where I got something

Re: [PATCH V5 0/4] Consolidated KVM vPMU support for x86

functions are changed accordingly (suggested by Joerg Rodel). Tested it again, works like a charm on my AMD system :) So for all patches again: Tested-by: Joerg Roedel jroe...@suse.de Thanks, Joerg -- To unsubscribe from this list: send the line unsubscribe kvm in the body

Re: [PATCH V5 2/4] KVM: x86/vPMU: Create vPMU interface for VMX and SVM

, which is initialized by sub-arch. Also note that Intel and AMD modules are now generated by combinig their corresponding arch files (vmx.c/svm.c) and pmu files (pmu_intel.c/pmu_amd.c). Tested-by: Radim Krčmář rkrc...@redhat.com Signed-off-by: Wei Huang w...@redhat.com Reviewed-by: Joerg

Re: [PATCH V4 2/4] KVM: x86/vPMU: Create vPMU interface for VMX and SVM

On Fri, Jun 05, 2015 at 01:20:14AM -0400, Wei Huang wrote: + + struct kvm_pmu_ops *(*get_pmu_ops)(void); Can't you just set kvm_pmu_ops in svm.c and vmx.c and save this call-back? Besides that the patch looks good. Joerg -- To unsubscribe from this list: send the line unsubscribe

Re: [PATCH V4 0/4] Consolidated KVM vPMU support for x86

(-) create mode 100644 arch/x86/kvm/pmu.h create mode 100644 arch/x86/kvm/pmu_amd.c create mode 100644 arch/x86/kvm/pmu_intel.c Okay, I reviewed and tested the series. It looks good to me, except for the one comment I had on patch 2. So feel free to add Reviewed-by: Joerg Roedel jroe

Re: [PATCH V4 2/4] KVM: x86/vPMU: Create vPMU interface for VMX and SVM

On Wed, Jun 10, 2015 at 01:47:42PM -0500, Wei Huang wrote: On 06/10/2015 01:05 PM, Joerg Roedel wrote: So how about putting the pmu-ops directly into the kvm_x86_ops as a (const) member, I like this idea better. Here is the (expanded) design: 1) add const struct kvm_pmu_ops *pmu_ops

Re: [PATCH V4 2/4] KVM: x86/vPMU: Create vPMU interface for VMX and SVM

On Wed, Jun 10, 2015 at 11:43:20AM -0500, Wei Huang wrote: On 06/10/2015 05:12 AM, Joerg Roedel wrote: On Fri, Jun 05, 2015 at 01:20:14AM -0400, Wei Huang wrote: + + struct kvm_pmu_ops *(*get_pmu_ops)(void); Can't you just set kvm_pmu_ops in svm.c and vmx.c and save this call-back

Re: [PATCH] kvm: irqchip: Break up high order allocations of kvm_irq_routing_table

Hi Paolo, On Mon, May 11, 2015 at 03:27:26PM +0200, Paolo Bonzini wrote: Great, I'll apply the patch. Gentle ping. I don't see the patch in the queue or next branches of the KVM tree yet. Do you plan to apply it for v4.2? Joerg -- To unsubscribe from this list: send the line

Re: [PATCH] kvm: irqchip: Break up high order allocations of kvm_irq_routing_table

Hi Paolo, On Fri, May 08, 2015 at 06:26:13PM +0200, Paolo Bonzini wrote: It probably doesn't matter much indeed, but can you time the difference? kvm_set_irq_routing is not too frequent, but happens enough often that we had to use a separate SRCU instance just to speed it up (see commit

[PATCH v2] kvm: iommu: Add cond_resched to legacy device assignment code

From: Joerg Roedel jroe...@suse.de When assigning devices to large memory guests (=128GB guest memory in the failure case) the functions to create the IOMMU page-tables for the whole guest might run for a very long time. On non-preemptible kernels this might cause Soft-Lockup warnings. Fix

Re: [PATCH] kvm: iommu: Add cond_resched to legacy device assignment code

On Wed, Dec 17, 2014 at 09:38:57AM +0800, Chen, Tiejun wrote: On 2014/12/16 23:47, Joerg Roedel wrote: diff --git a/virt/kvm/iommu.c b/virt/kvm/iommu.c index c1e6ae9..ac427e8 100644 --- a/virt/kvm/iommu.c +++ b/virt/kvm/iommu.c This file is already gone after one latest commit c274e03af705

Re: [PATCH] kvm: iommu: Add cond_resched to legacy device assignment code

On Wed, Dec 17, 2014 at 11:46:24AM +0100, Paolo Bonzini wrote: On 17/12/2014 11:35, Joerg Roedel wrote: This file is already gone after one latest commit c274e03af705, kvm: x86: move assigned-dev.c and iommu.c to arch/x86/ is introduced, so you need to pull your tree firstly

[PATCH] kvm: iommu: Add cond_resched to legacy device assignment code

From: Joerg Roedel jroe...@suse.de When assigning devices to large memory guests (=128GB guest memory in the failure case) the functions to create the IOMMU page-tables for the whole guest might run for a very long time. On non-preemptible kernels this might cause Soft-Lockup warnings. Fix

Re: [PATCHv7 02/26] iommu: add capability IOMMU_CAP_NOEXEC

IOMMU_CAP_INTR_REMAP 0x2 /* isolates device intrs */ +#define IOMMU_CAP_NOEXEC 0x3 /* IOMMU_NOEXEC flag */ This changed recently to an enum, please rebase to latest iommu/next branch. With that change: Acked-by: Joerg Roedel jroe...@suse.de for patches 1 and 2

Re: [PATCH kvm-unit-tests 1/3] x86: svm: fix exitinfo values for NPT tests

On Tue, Sep 02, 2014 at 05:05:26PM +0200, Paolo Bonzini wrote: The exitinfo values were plain wrong for the page-walk tests (including npt_rsvd), or else they were missing bits 32:33. Expect the right values. Are bits 32:33 really emulated? IIRC they were not emulated in the inital

Re: [PATCH 2/4] KVM: nSVM: propagate the NPF EXITINFO to the guest

Ah, here you add emulation of these bits. On Tue, Sep 02, 2014 at 05:13:48PM +0200, Paolo Bonzini wrote: This is similar to what the EPT code does with the exit qualification. This allows the guest to see a valid value for bits 33:32. Signed-off-by: Paolo Bonzini pbonz...@redhat.com ---

Re: [PATCH 2/4] KVM: nSVM: propagate the NPF EXITINFO to the guest

On Tue, Sep 02, 2014 at 06:46:06PM +0200, Paolo Bonzini wrote: Il 02/09/2014 18:33, Joerg Roedel ha scritto: Comment is true, but doesn't make the check below obsolete, no? No, it doesn't. I'll rewrite it as /* * This cannot happen unless the guest is playing TOCTTOU games

LPC IOMMU and VFIO MicroConference - Call for Participation

your formal proposal on the Linux Plumbers website (OpenID login required) until August 31st at: http://www.linuxplumbersconf.org/2014/how-to-submit-microconference-discussions-topics/ Hope to see you in Düsseldorf! Joerg Roedel and Alex Williamson -- To unsubscribe from

Re: [PATCH] KVM: nSVM: Do not report CLTS via SVM_EXIT_WRITE_CR0 to L1

...@siemens.com Reviewed-by: Joerg Roedel jroe...@suse.de Acked-by: Joerg Roedel jroe...@suse.de -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH] KVM: nSVM: Fix IOIO bitmap evaluation

. Signed-off-by: Jan Kiszka jan.kis...@siemens.com Reviewed-by: Joerg Roedel jroe...@suse.de Acked-by: Joerg Roedel jroe...@suse.de I have the slight hope that this fixes the issues with L2 Linux guests on L1 Windows hypervisors. Have to check that at some point :) - if (kvm_read_guest(svm-vcpu.kvm

Re: [PATCH] KVM: nSVM: Set correct port for IOIO interception evaluation

value from the instruction emulator instead. Signed-off-by: Jan Kiszka jan.kis...@siemens.com Reviewed-by: Joerg Roedel jroe...@suse.de Acked-by: Joerg Roedel jroe...@suse.de -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org

Re: [RFC PATCH v6 04/20] iommu/arm-smmu: add capability IOMMU_CAP_INTR_REMAP

On Sun, Jun 08, 2014 at 12:31:29PM +0200, Christoffer Dall wrote: On Thu, Jun 05, 2014 at 07:03:12PM +0200, Antonios Motakis wrote: With an ARM SMMU, interrupt remapping should always be safe from the SMMU's point of view, as it is properly handled by the GIC. Signed-off-by: Antonios

Re: [RFC PATCH v6 04/20] iommu/arm-smmu: add capability IOMMU_CAP_INTR_REMAP

On Mon, Jun 16, 2014 at 04:13:29PM +0100, Will Deacon wrote: MSIs look just like memory accesses made by the device, so the SMMU will translate them to point at the GIC ITS (doorbell). The ITS then has tables to work out how to route the MSI. So, if IOMMU_CAP_INTR_REMAP is simply supposed to

Re: [RFC PATCH v6 04/20] iommu/arm-smmu: add capability IOMMU_CAP_INTR_REMAP

On Mon, Jun 16, 2014 at 04:25:26PM +0100, Will Deacon wrote: Ok, thanks. In which case, I think this is really a combined property of the SMMU and the interrupt controller, so we might need some extra code so that the SMMU can check that the interrupt controller for the device is also capable

Re: Another preempt folding issue?

On Wed, Feb 12, 2014 at 11:40:17AM +0100, Borislav Petkov wrote: Also what I'm wondering about and what's not clear from Stefan's reply is whether this is purely a 32-bit issue, i.e. a 32-bit host running a 64-bit qemu running a 32-bit iso or what is it? Or do we have reports for both 32-bit

Re: Vga passthrough to KVM Guest issues

Hey Max, On Mon, Oct 28, 2013 at 10:17:19AM -0600, Alex Williamson wrote: On Wed, 2013-10-16 at 21:08 +0200, Max Schettler wrote: Hi guys, Im trying to set up vga passthrough. I use the latest mainline kernel (3.12rc5) and patched qemu (1.6.50). When i try to start a VM using this

Re: Vga passthrough to KVM Guest issues

On Fri, Nov 01, 2013 at 05:35:38PM +0100, Max Schettler wrote: I fixed this issue in the meanwhile by switching to another Mainboard, so I guess it was at least somehow associated with the Hardware. The first Setup was this one: AMD FX-8350 Gigabyte 970A-UD3 Gigabyte 7870GHz Edition

Re: [PATCH] intel-iommu: Fix leaks in pagetable freeing

On Sat, Jun 15, 2013 at 10:27:19AM -0600, Alex Williamson wrote: At best the current code only seems to free the leaf pagetables and the root. If you're unlucky enough to have a large gap (like any QEMU guest with more than 3G of memory), only the first chunk of leaf pagetables are freed

Re: I/O port permission bit inheritance between threads

Hey Stephen, On Mon, May 20, 2013 at 02:24:31PM -0700, Stephen Hemminger wrote: ioperm() inheritance across threads is different in KVM then when run on physical hardware. The following program runs on physical hardware but get SEGV under KVM. It appears that the I/O permission bits are

Re: [PATCH] kvm:x86/svm: enable SVM lock if host supports it

On Wed, Apr 17, 2013 at 11:03:33PM +0530, prasadjoshi.li...@gmail.com wrote: From: Prasad Joshi prasadjoshi.li...@gmail.com SVM lock features allows software from preventing update to EFER.SVME. Enable the SVM lock in guest if it is supported on host machine. Signed-off-by: Prasad Joshi

Re: RFC: vfio API changes needed for powerpc (v3)

On Tue, Apr 09, 2013 at 01:22:15AM +, Yoder Stuart-B08248 wrote: What happens if a normal unmap call is done on the MSI iova? Do we need a separate unmap? I was thinking a normal unmap on an MSI windows would be an error...but I'm not set on that. I put the msi unmap there to make

Re: [PATCH] KVM: nSVM/nVMX: Implement vmexit on INIT assertion

On Sun, Feb 24, 2013 at 03:08:53PM +0100, Jan Kiszka wrote: From: Jan Kiszka jan.kis...@siemens.com @@ -2390,6 +2390,21 @@ static int nested_svm_vmexit(struct vcpu_svm *svm) return 0; } +static bool nested_svm_handle_init_received(struct kvm_vcpu *vcpu) +{ + struct vcpu_svm

Re: [PATCH] KVM: nSVM/nVMX: Implement vmexit on INIT assertion

On Mon, Feb 25, 2013 at 10:04:50AM +0100, Jan Kiszka wrote: Is the nested-related state already saved on AMD, Jörg? If not, adding this one would not make things worse at least. Still, missing user space save/restore already breaks reset, not only migration (dunno if this is better on AMD).

Re: [PATCH] KVM: nVMX: Fix direct injection of interrupts from L0 to L2

On Tue, Feb 19, 2013 at 11:04:01AM +0100, Jan Kiszka wrote: I had a look at SVM to check how it deals with this, but I'm not sure if I understand the logic correctly. SVM does: static int nested_svm_vmexit(struct vcpu_svm *svm) { ... /* * If we emulate a VMRUN/#VMEXIT

[PATCH 2/2] kvm, svm: Update MAINTAINERS entry

I have no access to my AMD email address anymore. Update entry in MAINTAINERS to the new address. Cc: Avi Kivity a...@redhat.com Cc: Marcelo Tosatti mtosa...@redhat.com Signed-off-by: Joerg Roedel j...@8bytes.org --- MAINTAINERS |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff

Re: AMD KVM Pci Passthrough reports device busy

Hi Andreas, On Wed, Jul 11, 2012 at 04:26:30PM +0200, Andreas Hartmann wrote: May I please ask, if you meanwhile could get any information about potential peer-to-peer communication between the functions of the following multifunction device: Good news: I actually found the right person to

Re: AMD KVM Pci Passthrough reports device busy

On Mon, Jun 25, 2012 at 07:55:55AM +0200, Andreas Hartmann wrote: Hello Joerg, Joerg Roedel wrote: On Tue, Jun 05, 2012 at 08:27:05AM -0600, Alex Williamson wrote: Joerg, the question is whether the multifunction device above allows peer-to-peer between functions that could bypass

Re: AMD KVM Pci Passthrough reports device busy

On Tue, Jun 05, 2012 at 08:27:05AM -0600, Alex Williamson wrote: Joerg, the question is whether the multifunction device above allows peer-to-peer between functions that could bypass the iommu. If not, we can make it the first entry in device specific acs enabled function I proposed:

[PATCH] kvm-unittests: Fix apic unittest for latest qemu-kvm

. Cc: Jan Kiszka jan.kis...@siemens.com Signed-off-by: Joerg Roedel joerg.roe...@amd.com --- x86/apic.c | 12 ++-- 1 files changed, 6 insertions(+), 6 deletions(-) diff --git a/x86/apic.c b/x86/apic.c index 2725b9a..50e77fc 100644 --- a/x86/apic.c +++ b/x86/apic.c @@ -139,8 +139,8

Re: [PATCH] KVM: X86: Add mmx movq emulation

On Sun, May 06, 2012 at 01:08:05PM +0300, Avi Kivity wrote: On 05/04/2012 02:47 PM, Joerg Roedel wrote: Add support to the MMX versions of the movq instructions to the instruction emulator. Also handle possible exceptions they may cause. This is already in (cbe2c9d30, e59717550e

Re: [PATCH] KVM: X86: Remove stale values from ctxt-memop before emulation

because the generated assembly uses dst.val as input and output so writeback shouldn't do anything wrong. The bsr and bsf unittests all pass again with this patch. Joerg From e9262f18e90111d32b584084c0b5564cbd728d65 Mon Sep 17 00:00:00 2001 From: Joerg Roedel joerg.roe...@amd.com Date: Mon, 7

Re: [PATCH] KVM: X86: Add mmx movq emulation

On Sun, May 06, 2012 at 01:08:05PM +0300, Avi Kivity wrote: This is already in (cbe2c9d30, e59717550e). Are you looking at master instead of next? Btw. your mail about the new git-workflow states something about an auto-next branch. But I don't see that branch in the KVM tree (looking at

Re: [PATCH] KVM: X86: Remove stale values from ctxt-memop before emulation

On Mon, May 07, 2012 at 01:18:01PM +0300, Avi Kivity wrote: On 05/07/2012 01:12 PM, Joerg Roedel wrote: The instruction emulation for bsrw is broken in KVM because the code always uses bsr with 32 or 64 bit operand size for emulation. Fix that by using emulate_2op_SrcV_nobyte() macro

Re: [PATCH] KVM: X86: Add mmx movq emulation

On Mon, May 07, 2012 at 01:30:48PM +0300, Avi Kivity wrote: On 05/07/2012 01:28 PM, Joerg Roedel wrote: On Sun, May 06, 2012 at 01:08:05PM +0300, Avi Kivity wrote: This is already in (cbe2c9d30, e59717550e). Are you looking at master instead of next? Btw. your mail about the new git

[PATCH] KVM: X86: Add mmx movq emulation

Add support to the MMX versions of the movq instructions to the instruction emulator. Also handle possible exceptions they may cause. Signed-off-by: Joerg Roedel joerg.roe...@amd.com --- arch/x86/include/asm/kvm_emulate.h |2 +- arch/x86/kvm/emulate.c | 155

  1   2   3   4   5   6   7   8   9   10   >