Re: [PATCH RFC v4 net-next 0/5] virtio_net: enabling tx interrupts

2014-12-02 Thread Jason Wang
On Tue, Dec 2, 2014 at 11:15 AM, Jason Wang jasow...@redhat.com wrote: On Mon, Dec 1, 2014 at 6:42 PM, Michael S. Tsirkin m...@redhat.com wrote: On Mon, Dec 01, 2014 at 06:17:03PM +0800, Jason Wang wrote: Hello: We used to orphan packets before transmission for virtio-net. This breaks

Re: [PATCH RFC v4 net-next 0/5] virtio_net: enabling tx interrupts

2014-12-02 Thread Michael S. Tsirkin
On Tue, Dec 02, 2014 at 08:15:02AM +0008, Jason Wang wrote: On Tue, Dec 2, 2014 at 11:15 AM, Jason Wang jasow...@redhat.com wrote: On Mon, Dec 1, 2014 at 6:42 PM, Michael S. Tsirkin m...@redhat.com wrote: On Mon, Dec 01, 2014 at 06:17:03PM +0800, Jason Wang wrote: Hello: We used to

Re: [PATCH RFC v4 net-next 0/5] virtio_net: enabling tx interrupts

2014-12-02 Thread Jason Wang
On Tue, Dec 2, 2014 at 5:43 PM, Michael S. Tsirkin m...@redhat.com wrote: On Tue, Dec 02, 2014 at 08:15:02AM +0008, Jason Wang wrote: On Tue, Dec 2, 2014 at 11:15 AM, Jason Wang jasow...@redhat.com wrote: On Mon, Dec 1, 2014 at 6:42 PM, Michael S. Tsirkin m...@redhat.com wrote:

Re: [PATCH RFC v4 net-next 0/5] virtio_net: enabling tx interrupts

2014-12-02 Thread Michael S. Tsirkin
On Tue, Dec 02, 2014 at 09:59:48AM +0008, Jason Wang wrote: On Tue, Dec 2, 2014 at 5:43 PM, Michael S. Tsirkin m...@redhat.com wrote: On Tue, Dec 02, 2014 at 08:15:02AM +0008, Jason Wang wrote: On Tue, Dec 2, 2014 at 11:15 AM, Jason Wang jasow...@redhat.com wrote: On Mon, Dec

RE: [PATCH RFC v4 net-next 0/5] virtio_net: enabling tx interrupts

2014-12-02 Thread David Laight
From: Jason Wang On Mon, Dec 01, 2014 at 06:17:03PM +0800, Jason Wang wrote: Hello: We used to orphan packets before transmission for virtio-net. This breaks socket accounting and can lead serveral functions won't work, e.g: - Byte Queue Limit depends on tx completion

Re: [PATCH RFC v4 net-next 0/5] virtio_net: enabling tx interrupts

2014-12-02 Thread Michael S. Tsirkin
On Tue, Dec 02, 2014 at 10:00:06AM +, David Laight wrote: From: Jason Wang On Mon, Dec 01, 2014 at 06:17:03PM +0800, Jason Wang wrote: Hello: We used to orphan packets before transmission for virtio-net. This breaks socket accounting and can lead serveral functions won't

3rd World Conference on Information Systems and Technologies (WorldCIST'15), Deadline: December 7

2014-12-02 Thread M. Lemos
Deadline: December 7, 2014 -- WorldCIST'15 - 3rd World Conference on Information Systems and Technologies Ponta Delgada, Azores *, Portugal 1 - 3 April 2015 http://www.aisti.eu/worldcist15/ -- * Azores is ranked as the second most beautiful archipelago in the world by National

[PATCH RFC 1/2] virtio_balloon: convert to virtio 1.0 endian-ness

2014-12-02 Thread Michael S. Tsirkin
balloon device is not part of virtio 1.0 spec. Still, it's easy enough to make it handle endian-ness exactly as other virtio 1.0 devices: what we gain from this, is that there's no need to special-case it in virtio core. Signed-off-by: Michael S. Tsirkin m...@redhat.com ---

[PATCH RFC 2/2] virtio_balloon: drop legacy_only

2014-12-02 Thread Michael S. Tsirkin
balloon is the only driver using legacy_only ATM. It turns out, it's easier to just make balloon support virtio 1.0 endian-ness and drop the flag from core. Signed-off-by: Michael S. Tsirkin m...@redhat.com --- include/linux/virtio.h | 2 -- drivers/virtio/virtio.c | 4

[PATCH RFC v5 02/19] virtio: cull virtio_bus_set_vdev_features

2014-12-02 Thread Cornelia Huck
The only user of this function was virtio-ccw, and it should use virtio_set_features() like everybody else: We need to make sure that bad features are masked out properly, which this function did not do. Reviewed-by: Thomas Huth th...@linux.vnet.ibm.com Signed-off-by: Cornelia Huck

[PATCH RFC v5 00/19] qemu: towards virtio-1 host support

2014-12-02 Thread Cornelia Huck
Another iteration of virtio-1 patches for qemu, as always available on git://github.com/cohuck/qemu virtio-1 This one seems to work together with the current vhost-next patches (well, I can ping :) Changes from v4: - add helpers for feature bit manipulation and checking - use 64 bit feature bits

[PATCH RFC v5 03/19] virtio: feature bit manipulation helpers

2014-12-02 Thread Cornelia Huck
Add virtio_{add,clear}_feature helper functions for manipulating a feature bits variable. This has some benefits over open coding: - add check that the bit is in a sane range - make it obvious at a glance what is going on - have a central point to change when we want to extend feature bits

[PATCH RFC v5 06/19] virtio: endianness checks for virtio 1.0 devices

2014-12-02 Thread Cornelia Huck
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 --- hw/virtio/virtio.c|6 +-

[PATCH RFC v5 07/19] virtio: allow virtio-1 queue layout

2014-12-02 Thread Cornelia Huck
For virtio-1 devices, we allow a more complex queue layout that doesn't require descriptor table and rings on a physically-contigous memory area: add virtio_queue_set_rings() to allow transports to set this up. Signed-off-by: Cornelia Huck cornelia.h...@de.ibm.com --- hw/virtio/virtio.c

[PATCH RFC v5 05/19] virtio: support more feature bits

2014-12-02 Thread Cornelia Huck
With virtio-1, we support more than 32 feature bits. Let's extend both host and guest features to 64, which should suffice for a while. vhost and migration have been ignored for now. Signed-off-by: Cornelia Huck cornelia.h...@de.ibm.com --- hw/9pfs/virtio-9p-device.c |2 +-

[PATCH RFC v5 04/19] virtio: add feature checking helpers

2014-12-02 Thread Cornelia Huck
Add a helper function for checking whether a bit is set in the guest features for a vdev as well as one that works on a feature bit set. Convert code that open-coded this: It cleans up the code and makes it easier to extend the guest feature bits. Signed-off-by: Cornelia Huck

[PATCH RFC v5 10/19] s390x/virtio-ccw: add virtio set-revision call

2014-12-02 Thread Cornelia Huck
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 gets disabled, we have to revert to the legacy behavior in case the

[PATCH RFC v5 08/19] dataplane: allow virtio-1 devices

2014-12-02 Thread Cornelia Huck
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 |4 +- hw/scsi/virtio-scsi-dataplane.c |2 +-

[PATCH RFC v5 09/19] s390x/css: Add a callback for when subchannel gets disabled

2014-12-02 Thread Cornelia Huck
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: Cornelia Huck cornelia.h...@de.ibm.com --- hw/s390x/css.c | 12

[PATCH RFC v5 13/19] virtio: allow to fail setting status

2014-12-02 Thread Cornelia Huck
virtio-1 allow setting of the FEATURES_OK status bit to fail if the negotiated feature bits are inconsistent: let's fail virtio_set_status() in that case and update virtio-ccw to post an error to the guest. Signed-off-by: Cornelia Huck cornelia.h...@de.ibm.com --- hw/s390x/virtio-ccw.c |

[PATCH RFC v5 14/19] s390x/virtio-ccw: enable virtio 1.0

2014-12-02 Thread Cornelia Huck
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 insertion(+), 1 deletion(-) diff --git a/hw/s390x/virtio-ccw.h

[PATCH RFC v5 17/19] virtio-net: enable virtio 1.0

2014-12-02 Thread Cornelia Huck
virtio-net (non-vhost) now should have everything in place to support virtio 1.0: let's enable the feature bit for it. Note that VIRTIO_F_VERSION_1 is technically a transport feature; once every device is ready for virtio 1.0, we can move setting this feature bit out of the individual devices.

[PATCH RFC v5 11/19] s390x/virtio-ccw: support virtio-1 set_vq format

2014-12-02 Thread Cornelia Huck
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 th...@linux.vnet.ibm.com Signed-off-by: Cornelia Huck cornelia.h...@de.ibm.com ---

[PATCH RFC v5 12/19] virtio: disallow late feature changes for virtio-1

2014-12-02 Thread Cornelia Huck
For virtio-1 devices, the driver must not attempt to set feature bits after it set FEATURES_OK in the device status. Simply reject it in that case. Signed-off-by: Cornelia Huck cornelia.h...@de.ibm.com --- hw/virtio/virtio.c | 16 ++-- include/hw/virtio/virtio.h |2 ++

[PATCH RFC v5 19/19] virtio-blk: revision specific feature bits

2014-12-02 Thread Cornelia Huck
Wire up virtio-blk to provide different feature bit sets depending on whether legacy or v1.0 has been requested. Note that VERSION_1 is still disabled due to missing ANY_LAYOUT support. Signed-off-by: Cornelia Huck cornelia.h...@de.ibm.com --- hw/block/virtio-blk.c | 19 +++ 1

[PATCH RFC v5 16/19] virtio-net: support longer header

2014-12-02 Thread Cornelia Huck
virtio-1 devices always use num_buffers in the header, even if mergeable rx buffers have not been negotiated. Signed-off-by: Cornelia Huck cornelia.h...@de.ibm.com --- hw/net/virtio-net.c | 21 +++-- 1 file changed, 15 insertions(+), 6 deletions(-) diff --git

[PATCH RFC v5 18/19] virtio: support revision-specific features

2014-12-02 Thread Cornelia Huck
Devices may support different sets of feature bits depending on which revision they're operating at. Let's give the transport a way to re-query the device about its features when the revision has been changed. Signed-off-by: Cornelia Huck cornelia.h...@de.ibm.com --- hw/s390x/virtio-ccw.c

Re: [PATCH RFC v5 07/19] virtio: allow virtio-1 queue layout

2014-12-02 Thread Michael S. Tsirkin
On Tue, Dec 02, 2014 at 02:00:15PM +0100, Cornelia Huck wrote: For virtio-1 devices, we allow a more complex queue layout that doesn't require descriptor table and rings on a physically-contigous memory area: add virtio_queue_set_rings() to allow transports to set this up. Signed-off-by:

Re: [PATCH RFC v5 07/19] virtio: allow virtio-1 queue layout

2014-12-02 Thread Cornelia Huck
On Tue, 2 Dec 2014 16:46:28 +0200 Michael S. Tsirkin m...@redhat.com wrote: On Tue, Dec 02, 2014 at 02:00:15PM +0100, Cornelia Huck wrote: For virtio-1 devices, we allow a more complex queue layout that doesn't require descriptor table and rings on a physically-contigous memory area: add

Re: [PATCH RFC v5 07/19] virtio: allow virtio-1 queue layout

2014-12-02 Thread Cornelia Huck
On Tue, 2 Dec 2014 15:54:44 +0100 Cornelia Huck cornelia.h...@de.ibm.com wrote: On Tue, 2 Dec 2014 16:46:28 +0200 Michael S. Tsirkin m...@redhat.com wrote: pa == -1ULL tricks look quite ugly. Can't we set desc/avail/used unconditionally, and drop the pa value? And have

Re: [PATCH net] Revert drivers/net: Disable UFO through virtio in macvtap and tun

2014-12-02 Thread Vlad Yasevich
On 11/11/2014 12:12 PM, Ben Hutchings wrote: This reverts commit 88e0e0e5aa722b193c8758c8b45d041de5316924 for the tap drivers, but leaves UFO disabled in virtio_net. libvirt at least assumes that tap features will never be dropped in new kernel versions, and doing so prevents migration of

Re: [PATCH RFC 1/2] virtio_balloon: convert to virtio 1.0 endian-ness

2014-12-02 Thread Cornelia Huck
On Tue, 2 Dec 2014 13:44:06 +0200 Michael S. Tsirkin m...@redhat.com wrote: balloon device is not part of virtio 1.0 spec. Still, it's easy enough to make it handle endian-ness exactly as other virtio 1.0 devices: what we gain from this, is that there's no need to special-case it in virtio

Re: [PATCH RFC v5 07/19] virtio: allow virtio-1 queue layout

2014-12-02 Thread Michael S. Tsirkin
On Tue, Dec 02, 2014 at 04:41:36PM +0100, Cornelia Huck wrote: void virtio_queue_set_num(VirtIODevice *vdev, int n, int num) { +/* + * For virtio-1 devices, the number of buffers may only be + * updated if the ring addresses have not yet been set up. Where does it say that? +

Re: [PATCH v13 10/11] pvqspinlock, x86: Enable PV qspinlock for KVM

2014-12-02 Thread Konrad Rzeszutek Wilk
On Wed, Oct 29, 2014 at 04:19:10PM -0400, Waiman Long wrote: 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

Re: [PATCH v13 10/11] pvqspinlock, x86: Enable PV qspinlock for KVM

2014-12-02 Thread Thomas Gleixner
On Wed, 29 Oct 2014, Waiman Long wrote: AIM7 XFS Disk Test (no overcommit) kernel JPMReal Time Sys TimeUsr Time - ---- PV ticketlock 25423737.08 98.95 5.44 PV

[PATCH net-next] virtio-net: don't do header check for dodgy gso packets

2014-12-02 Thread Jason Wang
There's no need to do header check for virito-net since: - Host set dodgy for all gso packets from guest and check the header. - Host should prepare for all kinds of evil packets from guest, since malicious guest can send any kinds of packet. So this patch sets NETIF_F_GSO_ROBUST for