On Thu, Dec 11, 2014 at 02:25:08PM +0100, Cornelia Huck wrote:
Add code that checks for the VERSION_1 feature bit in order to make
decisions about the device's endianness. This allows us to support
transitional devices.
Signed-off-by: Cornelia Huck cornelia.h...@de.ibm.com
---
On (Wed) 14 Jan 2015 [19:27:35], Michael S. Tsirkin wrote:
Some devices might not implement config space access
(e.g. remoteproc used not to - before 3.9).
virtio/console needs config space access so make it
fail gracefully if not there.
Do we know any such devices? Wondering what prompted
On Thu, Dec 11, 2014 at 02:25:17PM +0100, Cornelia Huck wrote:
Devices operating as virtio 1.0 may not allow writes to the mac
address in config space.
Signed-off-by: Cornelia Huck cornelia.h...@de.ibm.com
---
hw/net/virtio-net.c |1 +
1 file changed, 1 insertion(+)
diff --git
On Thu, Dec 11, 2014 at 02:25:13PM +0100, Cornelia Huck wrote:
Support the new CCW_CMD_SET_VQ format for virtio-1 devices.
While we're at it, refactor the code a bit and enforce big endian
fields (which had always been required, even for legacy).
Reviewed-by: Thomas Huth
On Fri, Dec 12, 2014 at 12:25:47PM +0100, Thomas Huth wrote:
On Fri, 12 Dec 2014 12:18:25 +0100
Cornelia Huck cornelia.h...@de.ibm.com wrote:
On Fri, 12 Dec 2014 11:55:38 +0100
Thomas Huth th...@linux.vnet.ibm.com wrote:
On Thu, 11 Dec 2014 14:25:14 +0100
Cornelia Huck
On Tue, 20 Jan 2015 10:43:31 +
Stefan Hajnoczi stefa...@gmail.com wrote:
On Thu, Dec 11, 2014 at 02:25:10PM +0100, Cornelia Huck wrote:
Handle endianness conversion for virtio-1 virtqueues correctly.
Note that dataplane now needs to be built per-target.
Signed-off-by: Cornelia
On Thu, Dec 11, 2014 at 02:25:12PM +0100, Cornelia Huck wrote:
@@ -608,6 +631,25 @@ static int virtio_ccw_cb(SubchDev *sch, CCW1 ccw)
}
}
break;
+case CCW_CMD_SET_VIRTIO_REV:
+len = sizeof(revinfo);
+if (ccw.count len || (check_len
On Thu, Dec 11, 2014 at 02:25:10PM +0100, Cornelia Huck wrote:
Handle endianness conversion for virtio-1 virtqueues correctly.
Note that dataplane now needs to be built per-target.
Signed-off-by: Cornelia Huck cornelia.h...@de.ibm.com
---
hw/block/dataplane/virtio-blk.c |
On Thu, Dec 11, 2014 at 02:25:11PM +0100, Cornelia Huck wrote:
From: Thomas Huth th...@linux.vnet.ibm.com
We need a possibility to run code when a subchannel gets disabled.
This patch adds the necessary infrastructure.
Signed-off-by: Thomas Huth th...@linux.vnet.ibm.com
Signed-off-by:
On Thu, Dec 11, 2014 at 02:25:16PM +0100, Cornelia Huck wrote:
virtio-ccw should now have everything in place to operate virtio 1.0
devices, so let's enable revision 1.
Signed-off-by: Cornelia Huck cornelia.h...@de.ibm.com
---
hw/s390x/virtio-ccw.h |2 +-
1 file changed, 1
On Thu, Dec 11, 2014 at 02:25:12PM +0100, Cornelia Huck wrote:
From: Thomas Huth th...@linux.vnet.ibm.com
Handle the virtio-ccw revision according to what the guest sets.
When revision 1 is selected, we have a virtio-1 standard device
with byteswapping for the virtio rings.
When a channel
On Tue, Jan 20, 2015 at 04:10:40PM +0530, Amit Shah wrote:
On (Wed) 14 Jan 2015 [19:27:35], Michael S. Tsirkin wrote:
Some devices might not implement config space access
(e.g. remoteproc used not to - before 3.9).
virtio/console needs config space access so make it
fail gracefully if not
On Thu, Dec 11, 2014 at 02:25:18PM +0100, Cornelia Huck wrote:
diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index ebbea60..7ee2bd6 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -373,15 +373,21 @@ static int peer_has_ufo(VirtIONet *n)
return n-has_ufo;
}
On Tue, Jan 20, 2015 at 12:56 PM, Cornelia Huck
cornelia.h...@de.ibm.com wrote:
On Tue, 20 Jan 2015 10:43:31 +
Stefan Hajnoczi stefa...@gmail.com wrote:
On Thu, Dec 11, 2014 at 02:25:10PM +0100, Cornelia Huck wrote:
@@ -154,15 +157,18 @@ bool vring_should_notify(VirtIODevice *vdev, Vring
This patch add a support for second version of the virtio-mmio device,
which follows OASIS Virtual I/O Device (VIRTIO) Version 1.0
specification.
Main changes:
1. The control register symbolic names use the new device/driver
nomenclature rather than the old guest/host one.
2. The driver
On Mon, 2015-01-19 at 18:36 +, Michael S. Tsirkin wrote:
Well, not quite: as of now I've got legacy block device driver happily
working on top of compliant (so v2 in MMIO speech) MMIO device - the
transport if completely transparent here.
Spec says explicitly it's an illegal
On Mon, Jan 19, 2015 at 12:07:00PM +0100, Gerd Hoffmann wrote:
Hi,
BTW: is there a tool (or pciutils patch) which can decode the virtio
capabilities?
Searched for a patch today, and all google found me was this mail asking
for one :-o
So I went ahead and coded one up. Attached.
On Mon, Jan 19, 2015 at 11:54:43AM +0100, Gerd Hoffmann wrote:
Hi,
I'm running 3.19-rc4 with this series applied in the guest, maybe I need
more?
Tried your vhost branch, rebased to 3.19-rc5 -- same result. Hmm.
cheers,
Gerd
Yes, it was all completely broken.
Looks like after
release function in modern driver is unused:
it's a left-over from when each driver had
to have its own release.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
drivers/virtio/virtio_pci_modern.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/virtio/virtio_pci_modern.c
On Tue, Jan 20, 2015 at 06:12:11PM +, Pawel Moll wrote:
This patch add a support for second version of the virtio-mmio device,
which follows OASIS Virtual I/O Device (VIRTIO) Version 1.0
specification.
Main changes:
1. The control register symbolic names use the new device/driver
virtio_pci_modern: fix up vendor capability macros
Gerd Hoffmann noticed that we implemented
capability layout from an old draft.
Unfortunately the code was copied to host as well,
so we didn't notice.
Luckily we caught this in time.
This fixes commit virtio_pci: macros for PCI layout offsets
virtio modern: fix up fallback logic
This bails out if modern driver succeeds - not what we wanted.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
drivers/virtio/virtio_pci_common.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git
virtio_pci_modern: fix up vendor capability
Gerd Hoffmann noticed that we implemented
capability layout from an old draft.
Unfortunately the code was copied to host as well,
so we didn't notice.
Luckily we caught this in time.
This fixes commit virtio_pci: modern driver
and should be smashed
virtio modern: fix up fallback logic with force_legacy
This bails out if legacy driver succeeds - not what we wanted.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
drivers/virtio/virtio_pci_common.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git
This patch add a support for second version of the virtio-mmio device,
which follows OASIS Virtual I/O Device (VIRTIO) Version 1.0
specification.
Main changes:
1. The control register symbolic names use the new device/driver
nomenclature rather than the old guest/host one.
2. The driver
On Tue, Jan 20, 2015 at 05:18:23PM +, Pawel Moll wrote:
On Mon, 2015-01-19 at 18:36 +, Michael S. Tsirkin wrote:
Well, not quite: as of now I've got legacy block device driver happily
working on top of compliant (so v2 in MMIO speech) MMIO device - the
transport if
On Tue, 2015-01-20 at 17:44 +, Michael S. Tsirkin wrote:
Good. But your current code will also try to support a mix: device that
uses the new transport underneath, but old layout and semantics on top.
It will not try to support the mix, but rather will not stop it from
working.
This has
On Tue, Jan 20, 2015 at 05:51:11PM +, Pawel Moll wrote:
On Tue, 2015-01-20 at 17:44 +, Michael S. Tsirkin wrote:
Good. But your current code will also try to support a mix: device that
uses the new transport underneath, but old layout and semantics on top.
It will not try to
v13-v14:
- Patches 1 2: Add queue_spin_unlock_wait() to accommodate commit
78bff1c86 from Oleg Nesterov.
- Fix the system hang problem when using PV qspinlock in an
over-committed guest due to a racing condition in the
pv_set_head_in_tail() function.
- Increase the MAYHALT_THRESHOLD
This patch introduces a new generic queue spinlock implementation that
can serve as an alternative to the default ticket spinlock. Compared
with the ticket spinlock, this queue spinlock should be almost as fair
as the ticket spinlock. It has about the same speed in single-thread
and it can be much
This patch makes the necessary changes at the x86 architecture
specific layer to enable the use of queue spinlock for x86-64. As
x86-32 machines are typically not multi-socket. The benefit of queue
spinlock may not be apparent. So queue spinlock is not enabled.
Currently, there is some
From: Peter Zijlstra pet...@infradead.org
Because the qspinlock needs to touch a second cacheline (the per-cpu
mcs_nodes[]); add a pending bit and allow a single in-word spinner
before we punt to the second cacheline.
It is possible so observe the pending bit without the locked bit when
the last
This is a preparatory patch that extracts out the following 2 code
snippets to prepare for the next performance optimization patch.
1) the logic for the exchange of new and previous tail code words
into a new xchg_tail() function.
2) the logic for clearing the pending bit and setting the
From: Peter Zijlstra pet...@infradead.org
When we detect a hypervisor (!paravirt, see qspinlock paravirt support
patches), revert to a simple test-and-set lock to avoid the horrors
of queue preemption.
Signed-off-by: Peter Zijlstra pet...@infradead.org
Signed-off-by: Waiman Long
Currently, atomic_cmpxchg() is used to get the lock. However, this
is not really necessary if there is more than one task in the queue
and the queue head don't need to reset the tail code. For that case,
a simple write to set the lock bit is enough as the queue head will
be the only one eligible
This patch adds the necessary KVM specific code to allow KVM to
support the CPU halting and kicking operations needed by the queue
spinlock PV code.
Two KVM guests of 20 CPU cores (2 nodes) were created for performance
testing in one of the following three configurations:
1) Only 1 VM is active
This patch adds para-virtualization support to the queue spinlock
code base with minimal impact to the native case. There are some
minor code changes in the generic qspinlock.c file which should be
usable in other architectures. The other code changes are specific
to x86 processors and so are all
This patch renames the paravirt_ticketlocks_enabled static key to a
more generic paravirt_spinlocks_enabled name.
Signed-off-by: Waiman Long waiman.l...@hp.com
Signed-off-by: Peter Zijlstra pet...@infradead.org
---
arch/x86/include/asm/spinlock.h |4 ++--
arch/x86/kernel/kvm.c
This patch adds the necessary XEN specific code to allow XEN to
support the CPU halting and kicking operations needed by the queue
spinlock PV code.
Signed-off-by: Waiman Long waiman.l...@hp.com
---
arch/x86/xen/spinlock.c | 149 +--
On Wed, Jan 21, 2015 at 11:44:52AM +0530, Amit Shah wrote:
On (Tue) 20 Jan 2015 [13:09:55], Michael S. Tsirkin wrote:
On Tue, Jan 20, 2015 at 04:10:40PM +0530, Amit Shah wrote:
On (Wed) 14 Jan 2015 [19:27:35], Michael S. Tsirkin wrote:
Some devices might not implement config space access
Sebastian Ott seb...@linux.vnet.ibm.com writes:
On Wed, 14 Jan 2015, Michael S. Tsirkin wrote:
}
-EXPORT_SYMBOL_GPL(pci_iomap);
+EXPORT_SYMBOL_GPL(pci_iomap_range);
+
+void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned long maxlen)
+{
+return pci_iomap_range(dev, bar, 0,
On (Tue) 20 Jan 2015 [13:09:55], Michael S. Tsirkin wrote:
On Tue, Jan 20, 2015 at 04:10:40PM +0530, Amit Shah wrote:
On (Wed) 14 Jan 2015 [19:27:35], Michael S. Tsirkin wrote:
Some devices might not implement config space access
(e.g. remoteproc used not to - before 3.9).
42 matches
Mail list logo
