The following changes since commit 0a2ce2ffc358da96792d514c1024b72c52be9cc1:
David Howells (1):
Fix FRV minimum slab/kmalloc alignment
are available in the git repository at:
ssh://master.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6-for-linus.git
master
Chris Lalancette (1):
virtio_net uses a timer to free old transmitted packets, rather than
leaving callbacks enabled all the time. If the host promises to
always notify us when the transmit ring is empty, we can free packets
at that point and avoid the timer.
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
---
drive
This is the lguest implementation of the VIRTIO_F_NOTIFY_ON_EMPTY feature.
It is currently only published for network devices, but it is turned on for
everyone.
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
---
Documentation/lguest/lguest.c | 12 ++--
1 file changed, 10 insertions(+)
virtio allows drivers to suppress callbacks (ie. interrupts) for
efficiency (no locking, it's just an optimization).
There's a similar mechanism for the host to suppress notifications
coming from the guest: in that case, we ignore the suppression if the
ring is completely full.
It turns out that
On Thursday 29 May 2008 19:08:26 Christian Borntraeger wrote:
> 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
On Thursday 29 May 2008 19:10:01 Christian Borntraeger wrote:
> Since commit 72e61eb40b55dd57031ec5971e810649f82b0259 (virtio: change
> config to guest endian) config space is no longer fixed endian.
>
> Lets change the virtio_blk_config variables.
Applied, thanks,
Rusty.
_
On Thursday 29 May 2008 19:08:01 Christian Borntraeger wrote:
> v is a pointer, to we have to use sizeof(*v) instead of sizeof(v).
How embarassing. Applied, thanks.
Rusty.
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https:
On Thu, May 29, 2008 at 11:32:51AM +0100, Mark McLoughlin wrote:
>
> Subject: [PATCH 1/1] tun: Do not use kmap_atomic() since memcpy_fromiovec()
> can sleep
>
> Signed-off-by: Mark McLoughlin <[EMAIL PROTECTED]>
Good catch!
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert
On Fri, 2008-04-18 at 11:17 +0800, Herbert Xu wrote:
> This patch avoids the correctness issue on the user-space mapping
> by just copying the memory.
>
> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> index 4c15dc4..d75cfd2 100644
> --- a/drivers/net/tun.c
> +++ b/drivers/net/tun.c
> +
Since commit 72e61eb40b55dd57031ec5971e810649f82b0259 (virtio: change config
to guest endian) config space is no longer fixed endian.
Lets change the virtio_blk_config variables.
Signed-off-by: Christian Borntraeger <[EMAIL PROTECTED]>
---
include/linux/virtio_blk.h |8
1 file chan
Rusty,
This patch is a prereq for the virtio_blk blocksize patch, please apply it
first.
Adding an u32 value to the virtio_blk_config unconvered a small bug the config
space defintions:
v is a pointer, to we have to use sizeof(*v) instead of sizeof(v).
Signed-off-by: Christian Borntraeger <[EM
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
On Thu, May 29 2008, Christian Borntraeger wrote:
> Am Donnerstag, 29. Mai 2008 schrieb Jens Axboe:
> > > > Just that u64 seems like overkill: u32?
> > >
> > > Definitely, u32 would be just fine, u64 is way overkill :-)
> >
> > Even u16 would work, the block layer doesn't use more than an unsigne
Am Donnerstag, 29. Mai 2008 schrieb Jens Axboe:
> > > Just that u64 seems like overkill: u32?
> >
> > Definitely, u32 would be just fine, u64 is way overkill :-)
>
> Even u16 would work, the block layer doesn't use more than an unsigned
> short for storing hardware sector size anyway.
Thanks, go
On Thu, May 29 2008, Rusty Russell wrote:
> On Tuesday 27 May 2008 19:04:59 Christian Borntraeger wrote:
> > Rusty, Jens,
> >
> > I need your opinion on the following patch. It seems to work, but I would
> > like to get some feedback if this patch is the right approach:
>
> Looks like the right ap
On Thu, May 29 2008, Jens Axboe wrote:
> On Thu, May 29 2008, Rusty Russell wrote:
> > On Tuesday 27 May 2008 19:04:59 Christian Borntraeger wrote:
> > > Rusty, Jens,
> > >
> > > I need your opinion on the following patch. It seems to work, but I would
> > > like to get some feedback if this patch
Am Donnerstag, 29. Mai 2008 schrieb Rusty Russell:
> On Tuesday 27 May 2008 19:04:59 Christian Borntraeger wrote:
> > Rusty, Jens,
> >
> > I need your opinion on the following patch. It seems to work, but I would
> > like to get some feedback if this patch is the right approach:
>
> Looks like the
On Tuesday 27 May 2008 19:04:59 Christian Borntraeger wrote:
> Rusty, Jens,
>
> I need your opinion on the following patch. It seems to work, but I would
> like to get some feedback if this patch is the right approach:
Looks like the right approach to me. Don't know about the block side of it...
On Tuesday 27 May 2008 21:20:47 Mark McLoughlin wrote:
> hdr->csum_start is the offset from the start of the ethernet
> header to the transport layer checksum field. skb->csum_start
> is the offset from skb->head.
>
> skb_partial_csum_set() assumes that skb->data points to the
> ethernet header - i
On Tuesday 27 May 2008 21:06:26 Mark McLoughlin wrote:
> 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 c
20 matches
Mail list logo
