similar to: [PATCH 5/6] virtio: de-structify virtio_block status byte

The following changes since commit 886c35fbcf6fb2eee15687efc2d64d99b6ad9a4a: Linus Torvalds (1): Merge branch 'for-linus' of git://git.kernel.org/.../ieee1394/linux1394-2.6 are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6-for-linus.git master Christian Borntraeger (1): virtio: export more headers to userspace

The following changes since commit 886c35fbcf6fb2eee15687efc2d64d99b6ad9a4a: Linus Torvalds (1): Merge branch 'for-linus' of git://git.kernel.org/.../ieee1394/linux1394-2.6 are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6-for-linus.git master Christian Borntraeger (1): virtio: export more headers to userspace

This patch splits the device status field of virtio-net into ro and rw byte. This would simplify the implementation of both host and guest and make the layout more clean. As VIRTIO_NET_S_ANNOUNCE is a rw bit, it was moved to bit 8 (0x100). btw. looks like there's no implementation that depends on VIRTIO_NET_S_ANNOUNCE, so the move is safe. Signed-off-by: Jason Wang <jasowang at

This patch splits the device status field of virtio-net into ro and rw byte. This would simplify the implementation of both host and guest and make the layout more clean. As VIRTIO_NET_S_ANNOUNCE is a rw bit, it was moved to bit 8 (0x100). btw. looks like there's no implementation that depends on VIRTIO_NET_S_ANNOUNCE, so the move is safe. Signed-off-by: Jason Wang <jasowang at

PCI, lguest and s390 can all only support 256-byte configuration space. So, this giant field broke just about everyone. Unfortunately, removing it is not so simple: we don't want to break old userspace, but we're going to want to re-use that part of the struct. So, modern users can #define VIRTIO_BLK_IDENTIFY_DEPRECATED to indicate that they know it's no longer in the config struct,

PCI, lguest and s390 can all only support 256-byte configuration space. So, this giant field broke just about everyone. Unfortunately, removing it is not so simple: we don't want to break old userspace, but we're going to want to re-use that part of the struct. So, modern users can #define VIRTIO_BLK_IDENTIFY_DEPRECATED to indicate that they know it's no longer in the config struct,

An embedded and charset-unspecified text was scrubbed... Name: cpumask:convert-drivers.patch Url: http://lists.linux-foundation.org/pipermail/virtualization/attachments/20090107/f459eb35/attachment.txt

An embedded and charset-unspecified text was scrubbed... Name: cpumask:convert-drivers.patch Url: http://lists.linux-foundation.org/pipermail/virtualization/attachments/20090107/f459eb35/attachment.txt

From: Mark McLoughlin <markmc at redhat.com> lguest (in rusty's use-tun-ringfd patch) assumes that the guest has updated its feature bits before setting its status to VIRTIO_CONFIG_S_DRIVER_OK. That's pretty reasonable, so let's make it so. Signed-off-by: Mark McLoughlin <markmc at redhat.com> Signed-off-by: Rusty Russell <rusty at rustcorp.com.au> ---

From: Mark McLoughlin <markmc at redhat.com> lguest (in rusty's use-tun-ringfd patch) assumes that the guest has updated its feature bits before setting its status to VIRTIO_CONFIG_S_DRIVER_OK. That's pretty reasonable, so let's make it so. Signed-off-by: Mark McLoughlin <markmc at redhat.com> Signed-off-by: Rusty Russell <rusty at rustcorp.com.au> ---

Rusty Russell <rusty at rustcorp.com.au> writes: > Jason Wang <jasowang at redhat.com> writes: >> It looks like there's no need for those two fields: >> >> - Unless there's a failure for the first refill try, rq->max should be always >> equal to the vring size. >> - rq->num is only used to determine the condition that we need to do the

Rusty Russell <rusty at rustcorp.com.au> writes: > Jason Wang <jasowang at redhat.com> writes: >> It looks like there's no need for those two fields: >> >> - Unless there's a failure for the first refill try, rq->max should be always >> equal to the vring size. >> - rq->num is only used to determine the condition that we need to do the

From: Rusty Russell <rusty at rustcorp.com.au> Date: Mon, 15 Jul 2013 11:13:25 +0930 > From: Michael S. Tsirkin <mst at redhat.com> > > For small packets we can simplify xmit processing > by linearizing buffers with the header: > most packets seem to have enough head room > we can use for this purpose. > Since existing hypervisors require that header > is the

From: Rusty Russell <rusty at rustcorp.com.au> Date: Mon, 15 Jul 2013 11:13:25 +0930 > From: Michael S. Tsirkin <mst at redhat.com> > > For small packets we can simplify xmit processing > by linearizing buffers with the header: > most packets seem to have enough head room > we can use for this purpose. > Since existing hypervisors require that header > is the

On Fri, Oct 31, 2014 at 10:28:00AM +1030, Rusty Russell wrote: > Herbert Xu <herbert at gondor.apana.org.au> writes: > > On Thu, Sep 18, 2014 at 08:37:45PM +0800, Amos Kong wrote: > >> From: Rusty Russell <rusty at rustcorp.com.au> > >> > >> The previous patch added one potential problem: we can still be > >> reading from a hwrng when

On Fri, Oct 31, 2014 at 10:28:00AM +1030, Rusty Russell wrote: > Herbert Xu <herbert at gondor.apana.org.au> writes: > > On Thu, Sep 18, 2014 at 08:37:45PM +0800, Amos Kong wrote: > >> From: Rusty Russell <rusty at rustcorp.com.au> > >> > >> The previous patch added one potential problem: we can still be > >> reading from a hwrng when

On Thu, Sep 18, 2014 at 08:37:45PM +0800, Amos Kong wrote: > From: Rusty Russell <rusty at rustcorp.com.au> > > The previous patch added one potential problem: we can still be > reading from a hwrng when it's unregistered. Add a wait for zero > in the hwrng_unregister path. > > Signed-off-by: Rusty Russell <rusty at rustcorp.com.au> You totally corrupted

On Thu, Sep 18, 2014 at 08:37:45PM +0800, Amos Kong wrote: > From: Rusty Russell <rusty at rustcorp.com.au> > > The previous patch added one potential problem: we can still be > reading from a hwrng when it's unregistered. Add a wait for zero > in the hwrng_unregister path. > > Signed-off-by: Rusty Russell <rusty at rustcorp.com.au> You totally corrupted

Hi Rusty, The linux-next kernel was failing my virtio-console test suite for a while. I looked into it today, and it's due to the virtqueue_add_buf() change that doesn't return > 0 values anymore. I found your commit that adjusts virtio_console.c, but you missed one instance where the return value mattered, and as a result not enough buffers were queued for the host to send in data.

Hi Rusty, The linux-next kernel was failing my virtio-console test suite for a while. I looked into it today, and it's due to the virtqueue_add_buf() change that doesn't return > 0 values anymore. I found your commit that adjusts virtio_console.c, but you missed one instance where the return value mattered, and as a result not enough buffers were queued for the host to send in data.