Re: [RFC PATCH] VFIO: Add a parameter to force nonthread IRQ

On Mon, Oct 26, 2015 at 09:37:14PM -0600, Alex Williamson wrote: > On Mon, 2015-10-26 at 18:20 -0700, Yunhong Jiang wrote: > > An option to force VFIO PCI MSI/MSI-X handler as non-threaded IRQ, > > even when CONFIG_IRQ_FORCED_THREADING=y. This is uselful when > > assigning a device to a guest with

RE: [PATCH v3 2/3] KVM: arm/arm64: Merge vgic_set_lr() and vgic_sync_lr_elrsr()

Hello! > > --- cut --- > > Additionally, remove unnecessary vgic_set_lr() and LR_STATE_PENDING check > > in vgic_unqueue_irqs(), because all these things are now done by the > > following vgic_retire_lr(). > > --- cut --- > > This does not explain the question I'm raising. > > After applying

[PATCH v4 1/3] KVM: arm/arm64: Optimize away redundant LR tracking

Currently we use vgic_irq_lr_map in order to track which LRs hold which IRQs, and lr_used bitmap in order to track which LRs are used or free. vgic_irq_lr_map is actually used only for piggy-back optimization, and can be easily replaced by iteration over lr_used. This is good because in future,

[PATCH v4 2/3] KVM: arm/arm64: Clean up vgic_retire_lr() and surroundings

1. Remove unnecessary 'irq' argument, because irq number can be retrieved from the LR. 2. Since cff9211eb1a1f58ce7f5a2d596b617928fd4be0e ("arm/arm64: KVM: Fix arch timer behavior for disabled interrupts ") LR_STATE_PENDING is queued back by vgic_retire_lr() itself. Also, it clears

[PATCH v4 3/3] KVM: arm/arm64: Merge vgic_set_lr() and vgic_sync_lr_elrsr()

Now we see that vgic_set_lr() and vgic_sync_lr_elrsr() are always used together. Merge them into one function, saving from second vgic_ops dereferencing every time. Signed-off-by: Pavel Fedin --- include/kvm/arm_vgic.h | 1 - virt/kvm/arm/vgic-v2.c | 5 -

[PATCH v4 0/3] KVM: arm/arm64: Clean up some obsolete code

Current KVM code has lots of old redundancies, which can be cleaned up. This patchset is actually a better alternative to http://www.spinics.net/lists/arm-kernel/msg430726.html, which allows to keep piggy-backed LRs. The idea is based on the fact that our code also maintains LR state in elrsr, and

[PATCH] KVM: arm: Fix crash in free_hyp_pgds() if timer initialization fails

After vGIC initialization succeeded, and timer initialization failed, the following crash can be observed on ARM32: kvm [1]: interrupt-controller@10484000 IRQ57 kvm [1]: kvm_arch_timer: can't find DT node Unable to handle kernel paging request at virtual address 90484000 pgd = c0003000 [90484000]

Re: [ANNOUNCE][RFC] KVMGT - the implementation of Intel GVT-g(full GPU virtualization) for KVM

Hi all, We are pleased to announce another update of Intel GVT-g for KVM. Intel GVT-g is a full GPU virtualization solution with mediated pass-through, starting from 4th generation Intel Core(TM) processors with Intel Graphics processors. A virtual GPU instance is maintained for each VM, with

[PATCH] vhost: fix performance on LE hosts

commit 2751c9882b947292fcfb084c4f604e01724af804 ("vhost: cross-endian support for legacy devices") introduced a minor regression: even with cross-endian disabled, and even on LE host, vhost_is_little_endian is checking is_le flag so there's always a branch. To fix, simply check

Re: [PATCH] vhost: fix performance on LE hosts

On Tue, 27 Oct 2015 11:37:39 +0200 "Michael S. Tsirkin" wrote: > commit 2751c9882b947292fcfb084c4f604e01724af804 ("vhost: cross-endian > support for legacy devices") introduced a minor regression: even with > cross-endian disabled, and even on LE host, vhost_is_little_endian is >

Re: Network hangs when communicating with host

[apologies for the delay -- I've been off for a week and am catching up on email] On Tue, Oct 20, 2015 at 09:58:51AM -0400, Sasha Levin wrote: > On 10/20/2015 09:42 AM, Dmitry Vyukov wrote: > > I now have another issue. My binary fails to mmap a file within lkvm > > sandbox. The same binary

Re: [RFC PATCH] VFIO: Add a parameter to force nonthread IRQ

On 27/10/2015 07:35, Yunhong Jiang wrote: > On Mon, Oct 26, 2015 at 09:37:14PM -0600, Alex Williamson wrote: >> On Mon, 2015-10-26 at 18:20 -0700, Yunhong Jiang wrote: >>> An option to force VFIO PCI MSI/MSI-X handler as non-threaded IRQ, >>> even when CONFIG_IRQ_FORCED_THREADING=y. This is

Re: [PATCH] vhost: fix performance on LE hosts

From: "Michael S. Tsirkin" Date: Tue, 27 Oct 2015 11:37:39 +0200 > commit 2751c9882b947292fcfb084c4f604e01724af804 ("vhost: cross-endian > support for legacy devices") introduced a minor regression: even with > cross-endian disabled, and even on LE host, vhost_is_little_endian

Re: [PATCH] KVM: PPC: Implement extension to report number of memslots

On 26/10/15 06:15, Paul Mackerras wrote: > On Fri, Oct 16, 2015 at 08:41:31AM +0200, Thomas Huth wrote: >> Yes, we'll likely need this soon! 32 slots are not enough... > > Would anyone object if I raised the limit for PPC to 512 slots? In the long run we should really make this somehow

Re: [PATCH] KVM: PPC: Implement extension to report number of memslots

On 26/10/15 06:15, Paul Mackerras wrote: > On Fri, Oct 16, 2015 at 08:41:31AM +0200, Thomas Huth wrote: >> Yes, we'll likely need this soon! 32 slots are not enough... > > Would anyone object if I raised the limit for PPC to 512 slots? In the long run we should really make this somehow

Re: [PATCH] vhost: fix performance on LE hosts

On Tue, Oct 27, 2015 at 06:32:55AM -0700, David Miller wrote: > From: "Michael S. Tsirkin" > Date: Tue, 27 Oct 2015 11:37:39 +0200 > > > commit 2751c9882b947292fcfb084c4f604e01724af804 ("vhost: cross-endian > > support for legacy devices") introduced a minor regression: even

Re: [RFC PATCH] vfio/type1: Do not support IOMMUs that allow bypass

[cc +iommu] On Tue, 2015-10-27 at 15:40 +, Will Deacon wrote: > On Fri, Oct 16, 2015 at 09:51:22AM -0600, Alex Williamson wrote: > > On Fri, 2015-10-16 at 16:03 +0200, Eric Auger wrote: > > > Hi Alex, > > > On 10/15/2015 10:52 PM, Alex Williamson wrote: > > > > We can only provide isolation

Re: [RFC PATCH] vfio/type1: Do not support IOMMUs that allow bypass

On Fri, Oct 16, 2015 at 09:51:22AM -0600, Alex Williamson wrote: > On Fri, 2015-10-16 at 16:03 +0200, Eric Auger wrote: > > Hi Alex, > > On 10/15/2015 10:52 PM, Alex Williamson wrote: > > > We can only provide isolation if DMA is forced through the IOMMU > > > aperture. Don't allow type1 to be

Re: [PATCH 0/3] kvmtool: don't overwrite /virt/init

Hi Oleg, On Thu, Oct 22, 2015 at 05:59:21PM +0200, Oleg Nesterov wrote: > On top of "[PATCH 0/3] kvmtool: tiny init fox x86_64" I sent. > > I simply can't understand why kvmtool always overwrites /virt/init. > This doesn't look right, especially because you can't pass "init=" > kernel argument

SALLAM ALEIKUM

صديقي العزيز أشعر أنك من العمر ما يكفي للحفاظ على أسرار والتعامل مع مسألة حساسة بشكل سري، وبعد دردشة لدينا القليل شعرت بداخلي بأنني يجب مناقشة اقتراحي معك بسبب المستوى الخاص من التفاهم. هذا هو السبب في أنني أريد أن تقصر هذه الصفقة السرية فيكم. يجب عليك أن تبقي هذه المحادثة على أنها

[PATCH 1/4] Provide simple noop dma ops

We are going to require dma_ops for several common drivers, even for systems that do have an identity mapping. Lets provide some minimal no-op dma_ops that can be used for that purpose. Signed-off-by: Christian Borntraeger --- include/linux/dma-mapping.h | 2 ++

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

Some of the alpha pci noop dma ops are identical to the common ones. Use them. Signed-off-by: Christian Borntraeger --- arch/alpha/kernel/pci-noop.c | 46 1 file changed, 4 insertions(+), 42 deletions(-) diff --git

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

As virtio-ccw now has dma ops, we can no longer default to the PCI ones. Make use of dev_archdata to keep the dma_ops per device. Signed-off-by: Christian Borntraeger --- arch/s390/include/asm/device.h | 6 +- arch/s390/include/asm/dma-mapping.h | 2 +-

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

This is an RFC to check if I am on the right track. There are some attempts to unify the dma ops (Christoph) as well as some attempts to make virtio use the dma API (Andy). At todays discussion at the kernel summit, we concluded that we want to use the same code on all platforms, whereever

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

With all infrastructure in place, lets provide dma_ops for virtio devices on s390. Signed-off-by: Christian Borntraeger --- drivers/s390/virtio/kvm_virtio.c | 2 ++ drivers/s390/virtio/virtio_ccw.c | 2 ++ 2 files changed, 4 insertions(+) diff --git

Re: [RFC PATCH] VFIO: Add a parameter to force nonthread IRQ

On Tue, Oct 27, 2015 at 10:29:28AM +0100, Paolo Bonzini wrote: > > > On 27/10/2015 07:35, Yunhong Jiang wrote: > > On Mon, Oct 26, 2015 at 09:37:14PM -0600, Alex Williamson wrote: > >> On Mon, 2015-10-26 at 18:20 -0700, Yunhong Jiang wrote: > >>> An option to force VFIO PCI MSI/MSI-X handler as

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

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

From: Andy Lutomirski Once virtio starts using the DMA API, we won't be able to safely DMA from the stack. virtio-net does a couple of config DMA requests from small stack buffers -- switch to using dynamically-allocated memory. This should have no effect on any

[PATCH 0/3] virtio DMA API core stuff

This switches virtio to use the DMA API unconditionally. I'm sure it breaks things, but it seems to work on x86 using virtio-pci, with and without Xen, and using both the modern 1.0 variant and the legacy variant. Andy Lutomirski (3): virtio_net: Stop doing DMA from the stack virtio_ring:

[PATCH 2/3] virtio_ring: Support DMA APIs

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 same thing, but this isn't always the case. For example, this never works on Xen

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

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 virtio hardware as well as virtio-pci running under Xen. We should clean up

[PATCH 1/3] context_tracking: remove duplicate enabled check

All calls to context_tracking_enter and context_tracking_exit are already checking context_tracking_is_enabled, except the context_tracking_user_enter and context_tracking_user_exit functions left in for the benefit of assembly calls. Pull the check up to those functions, by making them simple

[PATCH 2/3] context_tracking: avoid irq_save/irq_restore on guest entry and exit

guest_enter and guest_exit must be called with interrupts disabled, since they take the vtime_seqlock with write_seq{lock,unlock}. Therefore, it is not necessary to check for exceptions, nor to save/restore the IRQ state, when context tracking functions are called by guest_enter and guest_exit.

[PATCH 3/3] x86: context_tracking: avoid irq_save/irq_restore on kernel entry and exit

x86 always calls user_enter and user_exit with interrupt disabled. Therefore, it is not necessary to check for exceptions, nor to save/restore the IRQ state, when context tracking functions are called by guest_enter and guest_exit. Use the previously introduced __context_tracking_entry and

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: [RFC PATCH] VFIO: Add a parameter to force nonthread IRQ

On 27/10/2015 22:26, Yunhong Jiang wrote: >> > On RT kernels however can you call eventfd_signal from interrupt >> > context? You cannot call spin_lock_irqsave (which can sleep) from a >> > non-threaded interrupt handler, can you? You would need a raw spin lock. > Thanks for pointing this out.

[PATCH 0/3] context_tracking: streamline code, avoid IRQ save/restore

The first two of these patches were posted last February, the last one is new. Rik's old measurements were that it shaved around .3 microseconds on each iteration of his KVM benchmark. I guess three days before the start of the merge window is not the best time to post patches. However, I

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

Am 28.10.2015 um 10:17 schrieb Andy Lutomirski: @@ -423,27 +522,42 @@ EXPORT_SYMBOL_GPL(virtqueue_kick); > > static void detach_buf(struct vring_virtqueue *vq, unsigned int head) > { > - unsigned int i; > + unsigned int i, j; > + u16 nextflag = cpu_to_virtio16(vq->vq.vdev,

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

On Tue, Oct 27, 2015 at 06:17:08PM -0700, Andy Lutomirski wrote: > From: Andy Lutomirski > > Once virtio starts using the DMA API, we won't be able to safely DMA > from the stack. virtio-net does a couple of config DMA requests > from small stack buffers -- switch to using

Re: [PATCH] KVM: x86: fix eflags state following processor init/reset

Ping, :-) On 10/21/15 2:28 PM, Wanpeng Li wrote: Reference SDM 3.4.3: Following initialization of the processor (either by asserting the RESET pin or the INIT pin), the state of the EFLAGS register is 0002H. However, the eflags fixed bit is not set and other bits are also not cleared

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

On Tue, Oct 27, 2015 at 7:27 PM, Christian Borntraeger wrote: > Am 28.10.2015 um 10:17 schrieb Andy Lutomirski: > @@ -423,27 +522,42 @@ EXPORT_SYMBOL_GPL(virtqueue_kick); >> >> static void detach_buf(struct vring_virtqueue *vq, unsigned int head) >> { >> - unsigned

Re: [PATCH 1/3] context_tracking: remove duplicate enabled check

On Tue, Oct 27, 2015 at 6:39 PM, Paolo Bonzini wrote: > All calls to context_tracking_enter and context_tracking_exit > are already checking context_tracking_is_enabled, except the > context_tracking_user_enter and context_tracking_user_exit > functions left in for the

Re: [PATCH 2/3] context_tracking: avoid irq_save/irq_restore on guest entry and exit

On Tue, Oct 27, 2015 at 6:39 PM, Paolo Bonzini wrote: > guest_enter and guest_exit must be called with interrupts disabled, > since they take the vtime_seqlock with write_seq{lock,unlock}. > Therefore, it is not necessary to check for exceptions, nor to > save/restore the IRQ

Re: [PATCH 0/3] context_tracking: streamline code, avoid IRQ save/restore

On 28/10/2015 02:39, Paolo Bonzini wrote: > The first two of these patches were posted last February, the last one > is new. Rik's old measurements were that it shaved around .3 microseconds > on each iteration of his KVM benchmark. > > I guess three days before the start of the merge window

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

On Tue, Oct 27, 2015 at 7:07 PM, Joerg Roedel wrote: > On Tue, Oct 27, 2015 at 06:17:08PM -0700, Andy Lutomirski wrote: >> From: Andy Lutomirski >> >> Once virtio starts using the DMA API, we won't be able to safely DMA >> from the stack. virtio-net does a

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 wrote: > > Hi Andy, > > > > On Tue, Oct 27, 2015 at 06:17:09PM -0700, Andy Lutomirski wrote: > >> From: Andy Lutomirski > >> > >> virtio_ring

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

On Wed, 2015-10-28 at 11:15 +0900, Joerg Roedel wrote: > 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

[PATCH v2 0/3] virtio DMA API core stuff

This switches virtio to use the DMA API unconditionally. I'm sure it breaks things, but it seems to work on x86 using virtio-pci, with and without Xen, and using both the modern 1.0 variant and the legacy variant. Changes from v1: - Fix an endian conversion error causing a BUG to hit. - Fix a

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

On Tue, Oct 27, 2015 at 7:06 PM, Joerg Roedel wrote: > 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

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. > I think a

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 the cases where dma_wmb()

Re: [PATCH] vhost: fix performance on LE hosts

From: "Michael S. Tsirkin" Date: Tue, 27 Oct 2015 11:37:39 +0200 > commit 2751c9882b947292fcfb084c4f604e01724af804 ("vhost: cross-endian > support for legacy devices") introduced a minor regression: even with > cross-endian disabled, and even on LE host, vhost_is_little_endian

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

On Tue, Oct 27, 2015 at 7:21 PM, Joerg Roedel wrote: > On Tue, Oct 27, 2015 at 07:13:56PM -0700, Andy Lutomirski wrote: >> On Tue, Oct 27, 2015 at 7:06 PM, Joerg Roedel wrote: >> > Hi Andy, >> > >> > On Tue, Oct 27, 2015 at 06:17:09PM -0700, Andy Lutomirski

Re: [PATCH 3/3] x86: context_tracking: avoid irq_save/irq_restore on kernel entry and exit

On Tue, Oct 27, 2015 at 6:39 PM, Paolo Bonzini wrote: > x86 always calls user_enter and user_exit with interrupt disabled. > Therefore, it is not necessary to check for exceptions, nor to > save/restore the IRQ state, when context tracking functions are > called by

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

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 same thing, but this isn't always the case. For example, this never works on Xen guests, and it is likely to fail if a physical

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

From: Andy Lutomirski Once virtio starts using the DMA API, we won't be able to safely DMA from the stack. virtio-net does a couple of config DMA requests from small stack buffers -- switch to using dynamically-allocated memory. This should have no effect on any

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

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 virtio hardware as well as virtio-pci running under Xen. We should clean up

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

Am 28.10.2015 um 14:30 schrieb Andy Lutomirski: > +static void vring_unmap_one(const struct vring_virtqueue *vq, > + struct vring_desc *desc) > +{ > + u16 flags = virtio16_to_cpu(vq->vq.vdev, desc->flags); > + > + if (flags & VRING_DESC_F_INDIRECT) { > +