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]
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
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, wh
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 vlr.s
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 -
virt/kvm/arm/vgic-v3.c | 5 -
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 uself
[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 works
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
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 virtio_legacy_is_li
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
> checking is_le fl
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 is
> checking is_le
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 dynamicall
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 use
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 with
> > cross-endian
[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 if
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 wi
صديقي العزيز
أشعر أنك من العمر ما يكفي للحفاظ على أسرار والتعامل مع مسألة حساسة
بشكل سري، وبعد دردشة لدينا القليل شعرت بداخلي بأنني يجب مناقشة اقتراحي معك بسبب
المستوى الخاص من التفاهم. هذا هو السبب في أنني أريد أن تقصر هذه الصفقة السرية
فيكم. يجب عليك أن تبقي هذه المحادثة على أنها س
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 n
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 +-
arch/s390/pci/pci.c
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
possib
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 a/drivers/s390/virtio/kvm_virtio.c b/drivers/
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 ++
lib/Makefile| 2
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 a/arch/alpha/kernel/pci-noop.c b/ar
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
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 = &dma_noop_ops;
> ret = ccw_
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
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.
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 guests, and
it is likely to
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 the virtqueue API to do
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 performance-critical code paths.
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: Sup
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 brough
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
wra
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.
Sp
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
__conte
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 is
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 same thing, but this isn'
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 dynamically-allocated
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 buffers. This is okay when DMA
>> add
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 couple of config DMA requests
>> from s
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 virtio hardware as well as
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 currently sends the device (usually a hype
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 IOMMU support until QEMU
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 g
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, VRING_DESC
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() i
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 is
> checking is_le
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 during
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 int i;
>> + unsigned i
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 wrote:
>> >> From: Andy Lutomirski
>>
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 benefit of assembly calls.
>
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 state, when context t
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 guest_enter and guest_exit.
>
>
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 D
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 "virt
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 performance-critical code paths.
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 the virtqueue API to do
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) {
> +
On Wed, 2015-10-28 at 14:52 +0900, Christian Borntraeger wrote:
>0059b25a: e3201024 lg %r2,32(%r1)
> #0059b260: e310b0a4 lg %r1,160(%r11)
> >0059b266: 4810100c lh %r1,12(%r1)
Precisely what is that
On Sun, 2015-10-25 at 09:07 -0700, Shamir Rabinovitch wrote:
>
> +
> +DMA_ATTR_IOMMU_BYPASS
> +-
> +
> > +For systems with IOMMU it is assumed all DMA translations use the IOMMU.
Not entirely true. We have per-device dma_ops on a most architectures
already, and we were just ta
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 performance-critical code paths.
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 v2:
- Fix really embarrassing bug. This version actually works.
Cha
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 the virtqueue API to do its own allocation and
t
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 "virt
On Tue, 2015-10-27 at 23:38 -0700, Andy Lutomirski wrote:
>
> Changes from v2:
> - Fix really embarrassing bug. This version actually works.
So embarrassing you didn't want to tell us what it was? ...
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -292,7 +292,7 @@ sta
65 matches
Mail list logo