Skip to content

L
linux-davinci
Switch branch/tag
  1. 25 Jul, 2008 14 commits
    • Rusty Russell's avatar
      virtio: Rename set_features to finalize_features · c624896e
      Rusty Russell authored 
      Rather than explicitly handing the features to the lower-level, we just
hand the virtio_device and have it set the features.  This make it clear
that it has the chance to manipulate the features of the device at this
point (and that all feature negotiation is already done).
Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      c624896e
    • Rusty Russell's avatar
      virtio: Formally reserve bits 28-31 to be 'transport' features. · dd7c7bc4
      Rusty Russell authored 
      We assign feature bits as required, but it makes sense to reserve some
for the particular transport, rather than the particular device.
Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      dd7c7bc4
    • Christian Borntraeger's avatar
      s390: use virtio_console for KVM on s390 · faeba830
      Christian Borntraeger authored 
      This patch enables virtio_console as the default console on kvm for
s390. We currently use the same notify hack as lguest for early
console output. I will try to address this for lguest and s390 later.
Signed-off-by: default avatarChristian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      faeba830
    • Christian Borntraeger's avatar
      virtio: console as a config option · 7721c494
      Christian Borntraeger authored 
      I also added a small Kconfig change that allows the user to specify the
virtio console in menuconfig.

(Fixes to export symbols from Stephen Rothwell <sfr@canb.auug.org.au>)
(Fixes for CONFIG_VIRTIO_CONSOLE=y vs CONFIG_VIRTIO=m from Christian himself)
Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      7721c494
    • Christian Borntraeger's avatar
      virtio_console: use virtqueue notification for hvc_console · 91fcad19
      Christian Borntraeger authored 
      This patch exploits the new notifier callbacks of the hvc_console. We can
use the virtio callbacks instead of the polling code.
Signed-off-by: default avatarChristian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      91fcad19
    • Christian Borntraeger's avatar
      hvc_console: rework setup to replace irq functions with callbacks · 611e097d
      Christian Borntraeger authored 
      This patch tries to change hvc_console to not use request_irq/free_irq if
the backend does not use irqs. This allows virtio_console to use hvc_console
without having a linker reference to request_irq/free_irq.

In addition, together with patch 2/3 it improves the performance for virtio
console input. (an earlier version of this patch was tested by Yajin on lguest)

The irq specific code is moved to hvc_irq.c and selected by the drivers that
use irqs (System p, System i, XEN).

I replaced "int irq" with the opaque "int data". The request_irq and
free_irq calls are replaced with notifier_add and notifier_del. I have also
changed the code a bit to call the notifier_add and notifier_del inside the
spinlock area as the callbacks are found via hp->ops.

Changes since last version:
o remove ifdef
o reintroduce "irq_requested" as "notified"
o cleanups, sparse..

I did not move the timer based polling into a separate polling scheme. I
played with several variants, but it seems we need to sleep/schedule in
a thread even for irq based consoles, as there are throttleing and buffer
size constraints.

I also kept hvc_struct defined in hvc_console.h so that hvc_irq.c can access
the irq_requested element.

Feedback is appreciated. virtio_console is currently the only available console
for kvm on s390. I plan to push this change as soon as all affected parties
agree on it. I would love to get test results from System p, Xen etc.
Signed-off-by: default avatarChristian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      611e097d
    • Christian Borntraeger's avatar
      virtio_blk: check for hardsector size from host · 066f4d82
      Christian Borntraeger authored 
      Currently virtio_blk assumes a 512 byte hard sector size. This can cause
trouble / performance issues if the backing has a different block size
(like a file on an ext3 file system formatted with 4k block size or a dasd).

Lets add a feature flag that tells the guest to use a different hard sector
size than 512 byte.
Signed-off-by: default avatarChristian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      066f4d82
    • Mark McLoughlin's avatar
      virtio: Use bus_type probe and remove methods · e962fa66
      Mark McLoughlin authored 
      Hook up to the probe() and remove() methods in bus_type
rather than device_driver. The latter has been preferred
since 2.6.16.
Signed-off-by: default avatarMark McLoughlin <markmc@redhat.com>
Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      e962fa66
    • Rusty Russell's avatar
      virtio: don't always force a notification when ring is full · 44653eae
      Rusty Russell authored 
      We force notification when the ring is full, even if the host has
indicated it doesn't want to know.  This seemed like a good idea at
the time: if we fill the transmit ring, we should tell the host
immediately.

Unfortunately this logic also applies to the receiving ring, which is
refilled constantly.  We should introduce real notification thesholds
to replace this logic.  Meanwhile, removing the logic altogether breaks
the heuristics which KVM uses, so we use a hack: only notify if there are
outgoing parts of the new buffer.

Here are the number of exits with lguest's crappy network implementation:
Before:
	network xmit 7859051 recv 236420
After:
	network xmit 7858610 recv 118136
Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      44653eae
    • Rusty Russell's avatar
      virtio: clarify that ABI is usable by any implementations · 674bfc23
      Rusty Russell authored 
      We want others to implement and use virtio, so it makes sense to BSD
license the non-__KERNEL__ parts of the headers to make this crystal
clear.
Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
Acked-by: default avatarChristian Borntraeger <borntraeger@de.ibm.com>
Acked-by: default avatarMark McLoughlin <markmc@redhat.com>
Acked-by: default avatarRyan Harper <ryanh@us.ibm.com>
Acked-by: default avatarEric Van Hensbergen <ericvh@gmail.com>
Acked-by: default avatarAnthony Liguori <aliguori@us.ibm.com>
      674bfc23
    • Rusty Russell's avatar
      virtio: Recycle unused recv buffer pages for large skbs in net driver · fb6813f4
      Rusty Russell authored 
      If we hack the virtio_net driver to always allocate full-sized (64k+)
skbuffs, the driver slows down (lguest numbers):

  Time to receive 1GB (small buffers): 10.85 seconds
  Time to receive 1GB (64k+ buffers): 24.75 seconds

Of course, large buffers use up more space in the ring, so we increase
that from 128 to 2048:

  Time to receive 1GB (64k+ buffers, 2k ring): 16.61 seconds

If we recycle pages rather than using alloc_page/free_page:

  Time to receive 1GB (64k+ buffers, 2k ring, recycle pages): 10.81 seconds

This demonstrates that with efficient allocation, we don't need to
have a separate "small buffer" queue.
Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      fb6813f4
    • Herbert Xu's avatar
      virtio net: Allow receiving SG packets · 97402b96
      Herbert Xu authored 
      Finally this patch lets virtio_net receive GSO packets in addition
to sending them.  This can definitely be optimised for the non-GSO
case.  For comparison the Xen approach stores one page in each skb
and uses subsequent skb's pages to construct an SG skb instead of
preallocating the maximum amount of pages per skb.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> (added feature bits)
      97402b96
    • Herbert Xu's avatar
      virtio net: Add ethtool ops for SG/GSO · a9ea3fc6
      Herbert Xu authored 
      This patch adds some basic ethtool operations to virtio_net so
I could test SG without GSO (which was really useful because TSO
turned out to be buggy :)

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> (remove MTU setting)
      a9ea3fc6
    • Mark McLoughlin's avatar
      virtio: fix virtio_net xmit of freed skb bug · 9953ca6c
      Mark McLoughlin authored 
      On Mon, 2008-05-26 at 17:42 +1000, Rusty Russell wrote:
> If we fail to transmit a packet, we assume the queue is full and put
> the skb into last_xmit_skb.  However, if more space frees up before we
> xmit it, we loop, and the result can be transmitting the same skb twice.
>
> Fix is simple: set skb to NULL if we've used it in some way, and check
> before sending.
...
> diff -r 564237b31993 drivers/net/virtio_net.c
> --- a/drivers/net/virtio_net.c	Mon May 19 12:22:00 2008 +1000
> +++ b/drivers/net/virtio_net.c	Mon May 19 12:24:58 2008 +1000
> @@ -287,21 +287,25 @@ again:
>  	free_old_xmit_skbs(vi);
>
>  	/* If we has a buffer left over from last time, send it now. */
> -	if (vi->last_xmit_skb) {
> +	if (unlikely(vi->last_xmit_skb)) {
>  		if (xmit_skb(vi, vi->last_xmit_skb) != 0) {
>  			/* Drop this skb: we only queue one. */
>  			vi->dev->stats.tx_dropped++;
>  			kfree_skb(skb);
> +			skb = NULL;
>  			goto stop_queue;
>  		}
>  		vi->last_xmit_skb = NULL;

With this, may drop an skb and then later in the function discover that
we could have sent it after all. Poor wee skb :)

How about the incremental patch below?

Cheers,
Mark.

Subject: [PATCH] virtio_net: Delay dropping tx skbs

Currently we drop the skb in start_xmit() if we have a
queued buffer and fail to transmit it.

However, if we delay dropping it until we've stopped the
queue and enabled the tx notification callback, then there
is a chance space might become available for it.
Signed-off-by: default avatarMark McLoughlin <markmc@redhat.com>
Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      9953ca6c
  3. 24 Jul, 2008 26 commits