From: Rusty Russell ru...@rustcorp.com.au
Another interesting anti-pattern.
Signed-off-by: Rusty Russell ru...@rustcorp.com.au
---
drivers/char/hw_random/core.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index
for triggering the cleanup
v3: initialize kref (thanks Amos Kong)
v2: fix missing put_rng() on exit path (thanks Amos Kong)
Signed-off-by: Rusty Russell ru...@rustcorp.com.au
Signed-off-by: Amos Kong ak...@redhat.com
---
drivers/char/hw_random/core.c | 135
In next patch, we use reference counting for each struct hwrng,
changing reference count also needs to take mutex_lock. Before
releasing the lock, if we try to stop a kthread that waits to
take the lock to reduce the referencing count, deadlock will
occur.
Signed-off-by: Amos Kong ak
From: Rusty Russell ru...@rustcorp.com.au
There's currently a big lock around everything, and it means that we
can't query sysfs (eg /sys/devices/virtual/misc/hw_random/rng_current)
while the rng is reading. This is a real problem when the rng is slow,
or blocked (eg. virtio_rng with qemu's
corrupt, decrease last reference for triggering
the cleanup, fix unregister race pointed by Herbert
V3: initialize kref to 1
V2: added patch 2 to fix a deadlock, update current patch 3 to fix reference
counting issue
Amos Kong (1):
hw_random: move some code out mutex_lock for avoiding
From: Rusty Russell ru...@rustcorp.com.au
Interesting anti-pattern.
Signed-off-by: Rusty Russell ru...@rustcorp.com.au
---
drivers/char/hw_random/core.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index
flag to insure that cleanup is done
Signed-off-by: Rusty Russell ru...@rustcorp.com.au
Signed-off-by: Amos Kong ak...@redhat.com
---
drivers/char/hw_random/core.c | 12
include/linux/hw_random.h | 1 +
2 files changed, 13 insertions(+)
diff --git a/drivers/char/hw_random/core.c b
On Wed, Nov 12, 2014 at 02:33:00PM +1030, Rusty Russell wrote:
Amos Kong ak...@redhat.com writes:
From: Rusty Russell ru...@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
flag to insure that cleanup is done
Signed-off-by: Rusty Russell ru...@rustcorp.com.au
Signed-off-by: Amos Kong ak...@redhat.com
---
drivers/char/hw_random/core.c | 12
include/linux/hw_random.h | 1 +
2 files changed, 13 insertions(+)
diff --git a/drivers/char/hw_random/core.c b
From: Rusty Russell ru...@rustcorp.com.au
Another interesting anti-pattern.
Signed-off-by: Rusty Russell ru...@rustcorp.com.au
---
drivers/char/hw_random/core.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index
From: Rusty Russell ru...@rustcorp.com.au
Interesting anti-pattern.
Signed-off-by: Rusty Russell ru...@rustcorp.com.au
---
drivers/char/hw_random/core.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index
for triggering the cleanup
v3: initialize kref (thanks Amos Kong)
v2: fix missing put_rng() on exit path (thanks Amos Kong)
Signed-off-by: Rusty Russell ru...@rustcorp.com.au
Signed-off-by: Amos Kong ak...@redhat.com
---
drivers/char/hw_random/core.c | 135
corrupt, decrease last reference for triggering
the cleanup, fix unregister race pointed by Herbert
V3: initialize kref to 1
V2: added patch 2 to fix a deadlock, update current patch 3 to fix reference
counting issue
Amos Kong (1):
hw_random: move some code out mutex_lock for avoiding
In next patch, we use reference counting for each struct hwrng,
changing reference count also needs to take mutex_lock. Before
releasing the lock, if we try to stop a kthread that waits to
take the lock to reduce the referencing count, deadlock will
occur.
Signed-off-by: Amos Kong ak
From: Rusty Russell ru...@rustcorp.com.au
There's currently a big lock around everything, and it means that we
can't query sysfs (eg /sys/devices/virtual/misc/hw_random/rng_current)
while the rng is reading. This is a real problem when the rng is slow,
or blocked (eg. virtio_rng with qemu's
On Wed, Nov 12, 2014 at 02:33:00PM +1030, Rusty Russell wrote:
Amos Kong ak...@redhat.com writes:
From: Rusty Russell ru...@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
On Wed, Nov 12, 2014 at 02:11:23PM +1030, Rusty Russell wrote:
Amos Kong ak...@redhat.com writes:
From: Rusty Russell ru...@rustcorp.com.au
current_rng holds one reference, and we bump it every time we want
to do a read from it.
This means we only hold the rng_mutex to grab or drop
On Tue, Oct 21, 2014 at 10:15:23PM +0800, Herbert Xu wrote:
On Thu, Sep 18, 2014 at 12:18:24PM +0930, Rusty Russell wrote:
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.
From: Rusty Russell ru...@rustcorp.com.au
Another interesting anti-pattern.
Signed-off-by: Rusty Russell ru...@rustcorp.com.au
---
drivers/char/hw_random/core.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index
In next patch, we use reference counting for each struct hwrng,
changing reference count also needs to take mutex_lock. Before
releasing the lock, if we try to stop a kthread that waits to
take the lock to reduce the referencing count, deadlock will
occur.
Signed-off-by: Amos Kong ak
kref to 1
V2: added patch 2 to fix a deadlock, update current patch 3 to fix reference
counting issue
Amos Kong (1):
hw_random: move some code out mutex_lock for avoiding underlying
deadlock
Rusty Russell (5):
hw_random: place mutex around read functions and buffers.
hw_random: use
: initialize kref (thanks Amos Kong)
v2: fix missing put_rng() on exit path (thanks Amos Kong)
Signed-off-by: Rusty Russell ru...@rustcorp.com.au
Signed-off-by: Amos Kong ak...@redhat.com
---
drivers/char/hw_random/core.c | 142 +-
include/linux/hw_random.h
From: Rusty Russell ru...@rustcorp.com.au
There's currently a big lock around everything, and it means that we
can't query sysfs (eg /sys/devices/virtual/misc/hw_random/rng_current)
while the rng is reading. This is a real problem when the rng is slow,
or blocked (eg. virtio_rng with qemu's
...@rustcorp.com.au
Signed-off-by: Amos Kong ak...@redhat.com
---
drivers/char/hw_random/core.c | 8
include/linux/hw_random.h | 1 +
2 files changed, 9 insertions(+)
diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index 27ad6b4..c31bf91 100644
--- a/drivers/char
From: Rusty Russell ru...@rustcorp.com.au
Interesting anti-pattern.
Signed-off-by: Rusty Russell ru...@rustcorp.com.au
---
drivers/char/hw_random/core.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index
On Fri, Oct 31, 2014 at 03:23:21PM +0800, Herbert Xu wrote:
On Fri, Oct 31, 2014 at 10:28:00AM +1030, Rusty Russell wrote:
Herbert Xu herb...@gondor.apana.org.au writes:
On Thu, Sep 18, 2014 at 08:37:45PM +0800, Amos Kong wrote:
From: Rusty Russell ru...@rustcorp.com.au
On Sun, Nov 02, 2014 at 11:08:09PM +0800, Herbert Xu wrote:
On Sun, Nov 02, 2014 at 11:06:13PM +0800, Amos Kong wrote:
On Fri, Oct 31, 2014 at 03:23:21PM +0800, Herbert Xu wrote:
On Fri, Oct 31, 2014 at 10:28:00AM +1030, Rusty Russell wrote:
Herbert Xu herb...@gondor.apana.org.au writes
On Mon, Oct 20, 2014 at 10:42:11AM +1030, Rusty Russell wrote:
Amos Kong ak...@redhat.com writes:
We got a warning in boot stage when above set_current_rng() is executed,
it can be fixed by init rng-ref in hwrng_init().
@@ -166,6 +169,8 @@ static inline int hwrng_init(struct hwrng *rng
On Thu, Sep 18, 2014 at 12:18:23PM +0930, Rusty Russell wrote:
current_rng holds one reference, and we bump it every time we want
to do a read from it.
This means we only hold the rng_mutex to grab or drop a reference,
so accessing /sys/devices/virtual/misc/hw_random/rng_current doesn't
From: Rusty Russell ru...@rustcorp.com.au
Another interesting anti-pattern.
Signed-off-by: Rusty Russell ru...@rustcorp.com.au
---
drivers/char/hw_random/core.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index
In next patch, we use reference counting for each struct hwrng,
changing reference count also needs to take mutex_lock. Before
releasing the lock, if we try to stop a kthread that waits to
take the lock to reduce the referencing count, deadlock will
occur.
Signed-off-by: Amos Kong ak
From: Rusty Russell ru...@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 ru...@rustcorp.com.au
---
drivers/char/hw_random/core.c | 2 ++
From: Rusty Russell ru...@rustcorp.com.au
Interesting anti-pattern.
Signed-off-by: Rusty Russell ru...@rustcorp.com.au
---
drivers/char/hw_random/core.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index
-by: Rusty Russell ru...@rustcorp.com.au
Signed-off-by: Amos Kong ak...@redhat.com
---
drivers/char/hw_random/core.c | 136 +-
include/linux/hw_random.h | 2 +
2 files changed, 95 insertions(+), 43 deletions(-)
diff --git a/drivers/char/hw_random/core.c b
patch 3 to fix reference
counting issue
Amos Kong (1):
hw_random: move some code out mutex_lock for avoiding underlying
deadlock
Rusty Russell (5):
hw_random: place mutex around read functions and buffers.
hw_random: use reference counts on each struct hwrng.
hw_random: fix
From: Rusty Russell ru...@rustcorp.com.au
There's currently a big lock around everything, and it means that we
can't query sysfs (eg /sys/devices/virtual/misc/hw_random/rng_current)
while the rng is reading. This is a real problem when the rng is slow,
or blocked (eg. virtio_rng with qemu's
On Thu, Sep 18, 2014 at 12:13:08PM +0930, Rusty Russell wrote:
Amos Kong ak...@redhat.com writes:
I started a QEMU (non-smp) guest with one virtio-rng device, and read
random data from /dev/hwrng by dd:
# dd if=/dev/hwrng of=/dev/null
In the same time, if I check hwrng attributes
On Thu, Sep 18, 2014 at 08:37:44PM +0800, Amos Kong wrote:
From: Rusty Russell ru...@rustcorp.com.au
current_rng holds one reference, and we bump it every time we want
to do a read from it.
This means we only hold the rng_mutex to grab or drop a reference,
so accessing /sys/devices
It doesn't save too much cpu time as expected, just a cleanup.
Signed-off-by: Amos Kong ak...@redhat.com
---
drivers/char/hw_random/core.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index aa30a25
This patch increases the schedule timeout to 10 jiffies, it's more
appropriate, then other takes can easy to hold the mutex lock.
Signed-off-by: Amos Kong ak...@redhat.com
---
drivers/char/hw_random/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/char/hw_random
the issue by changing rng_dev_read() to always
schedule 10 jiffies after release mutex lock, then cat process can
have chance to get the lock and execute protected code without stuck.
Thanks.
V2: update commitlog to describe PATCH 2, split second patch.
Amos Kong (3):
virtio-rng cleanup: move
removed need_resched() and always schedule other tasks
then other tasks can have chance to hold the lock and execute
protected code.
Signed-off-by: Amos Kong ak...@redhat.com
---
drivers/char/hw_random/core.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/char/hw_random
On Mon, Sep 15, 2014 at 06:13:31PM +0200, Michael Büsch wrote:
On Tue, 16 Sep 2014 00:02:29 +0800
Amos Kong ak...@redhat.com wrote:
This patch increases the schedule timeout to 10 jiffies, it's more
appropriate, then other takes can easy to hold the mutex lock.
Signed-off-by: Amos
On Mon, Sep 15, 2014 at 06:13:20PM +0200, Michael Büsch wrote:
On Tue, 16 Sep 2014 00:02:27 +0800
Amos Kong ak...@redhat.com wrote:
It doesn't save too much cpu time as expected, just a cleanup.
Signed-off-by: Amos Kong ak...@redhat.com
---
drivers/char/hw_random/core.c | 6
CC linux-kernel
Original thread:
http://comments.gmane.org/gmane.linux.kernel.virtualization/22775
On Mon, Sep 15, 2014 at 06:48:46PM +0200, Radim Krčmář wrote:
2014-09-14 10:25+0800, Amos Kong:
On Sun, Sep 14, 2014 at 09:12:08AM +0800, Amos Kong wrote:
...
diff --git a/drivers
On Thu, Sep 11, 2014 at 09:08:03PM +0930, Rusty Russell wrote:
Amos Kong ak...@redhat.com writes:
When I check hwrng attributes in sysfs, cat process always gets
stuck if guest has only 1 vcpu and uses a slow rng backend.
Currently we check if there is any tasks waiting to be run
On Sun, Sep 14, 2014 at 01:12:58AM +0800, Amos Kong wrote:
On Thu, Sep 11, 2014 at 09:08:03PM +0930, Rusty Russell wrote:
Amos Kong ak...@redhat.com writes:
When I check hwrng attributes in sysfs, cat process always gets
stuck if guest has only 1 vcpu and uses a slow rng backend
On Thu, Sep 11, 2014 at 11:38:38AM +0530, Amit Shah wrote:
On (Wed) 10 Sep 2014 [17:07:07], Amos Kong wrote:
When I check hwrng attributes in sysfs, cat process always gets
stuck if guest has only 1 vcpu and uses a slow rng backend.
Currently we check if there is any tasks waiting
On Sun, Sep 14, 2014 at 09:12:08AM +0800, Amos Kong wrote:
...
diff --git a/drivers/char/hw_random/core.c
b/drivers/char/hw_random/core.c
index c591d7e..b5d1b6f 100644
--- a/drivers/char/hw_random/core.c
+++ b/drivers/char/hw_random/core.c
@@ -195,8 +195,7 @@ static
.
Thanks for the help of Amit.
Cc: sta...@vger.kernel.org
V2: reset data_avail (Amit)
adjust unregister order
V3: split patch, update commitlog
Amos Kong (2):
virtio-rng: fix stuck of hot-unplugging busy device
virtio-rng: skip reading when we start to remove the device
drivers/char/hw_random
use wrong
buffer bytes.
Signed-off-by: Amos Kong ak...@redhat.com
Cc: sta...@vger.kernel.org
---
drivers/char/hw_random/virtio-rng.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/char/hw_random/virtio-rng.c
b/drivers/char/hw_random/virtio-rng.c
index 2e3139e..849b228 100644
Before we really unregister the hwrng device, reading will get stuck if
the virtio device is reset. We should return error for reading when we
start to remove the device.
Signed-off-by: Amos Kong ak...@redhat.com
Cc: sta...@vger.kernel.org
---
drivers/char/hw_random/virtio-rng.c | 5 +
1
On Wed, Sep 10, 2014 at 11:04:54AM +0530, Amit Shah wrote:
Hi Amos,
On (Tue) 09 Sep 2014 [19:14:02], Amos Kong wrote:
When we try to hot-remove a busy virtio-rng device from QEMU monitor,
the device can't be hot-removed. Because virtio-rng driver hangs at
wait_for_completion_killable
On Wed, Sep 10, 2014 at 11:22:12AM +0530, Amit Shah wrote:
On (Tue) 09 Sep 2014 [23:23:07], Amos Kong wrote:
(Resend to fix the subject)
Hi Amit, Rusty
RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1127062
steps:
- Read random data by 'dd if=/dev/hwrng of=/dev/null' in guest
On Wed, Sep 10, 2014 at 02:49:38PM +0800, Amos Kong wrote:
On Wed, Sep 10, 2014 at 11:22:12AM +0530, Amit Shah wrote:
On (Tue) 09 Sep 2014 [23:23:07], Amos Kong wrote:
(Resend to fix the subject)
Hi Amit, Rusty
RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1127062
steps
() is executing in user context.
This patch removed need_resched() and increase delay to 10 jiffies,
then other tasks can have chance to execute protected code.
Delaying 1 jiffy also works, but 10 jiffies is safer.
Signed-off-by: Amos Kong ak...@redhat.com
---
drivers/char/hw_random/core.c | 3 +--
1 file
It doesn't save too much cpu time as expected, just a cleanup.
Signed-off-by: Amos Kong ak...@redhat.com
---
drivers/char/hw_random/core.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index aa30a25
to execute protected code, the problem is resolved.
Thanks.
Amos Kong (2):
virtio-rng cleanup: move some code out of mutex protection
virtio-rng: fix stuck in catting hwrng attributes
drivers/char/hw_random/core.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
--
1.9.3
On Mon, Sep 08, 2014 at 11:29:51PM +0800, Amos Kong wrote:
On Wed, Aug 06, 2014 at 01:55:29PM +0530, Amit Shah wrote:
On (Wed) 06 Aug 2014 [16:05:41], Amos Kong wrote:
On Wed, Aug 06, 2014 at 01:35:15AM +0800, Amos Kong wrote:
When we try to hot-remove a busy virtio-rng device from QEMU
use wrong
buffer bytes. Before real unregistering we should return -ENODEV for
reading.
When we hot-unplug the device, dd process in guest will exit.
$ dd if=/dev/hwrng of=/dev/null
dd: error reading ‘/dev/hwrng’: No such device
Signed-off-by: Amos Kong ak...@redhat.com
Cc: sta
Hi Amit, Rusty
RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1127062
steps:
- Read random data by 'dd if=/dev/hwrng of=/dev/null' in guest
- check sysfs files in the same time, 'cat /sys/class/misc/hw_random/rng_*'
Result: cat process will get stuck, it will return if we kill dd process.
We
(Resend to fix the subject)
Hi Amit, Rusty
RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1127062
steps:
- Read random data by 'dd if=/dev/hwrng of=/dev/null' in guest
- check sysfs files in the same time, 'cat /sys/class/misc/hw_random/rng_*'
Result: cat process will get stuck, it will
On Wed, Aug 06, 2014 at 01:55:29PM +0530, Amit Shah wrote:
On (Wed) 06 Aug 2014 [16:05:41], Amos Kong wrote:
On Wed, Aug 06, 2014 at 01:35:15AM +0800, Amos Kong wrote:
When we try to hot-remove a busy virtio-rng device from QEMU monitor,
the device can't be hot-removed. Because virtio-rng
On Mon, Sep 01, 2014 at 09:37:30AM +0300, Michael S. Tsirkin wrote:
Hi Michael,
On Mon, Sep 01, 2014 at 01:41:54PM +0800, Amos Kong wrote:
One VM only has 128 msix interrupt, virtio-config interrupt
has less workload. This patch shares one normal interrupt
Thanks for your quick reply
One VM only has 128 msix interrupt, virtio-config interrupt
has less workload. This patch shares one normal interrupt
for configuration between virtio devices.
Signed-off-by: Amos Kong ak...@redhat.com
---
drivers/virtio/virtio_pci.c | 41 -
1 file changed
On Wed, Aug 06, 2014 at 01:35:15AM +0800, Amos Kong wrote:
When we try to hot-remove a busy virtio-rng device from QEMU monitor,
the device can't be hot-removed. Because virtio-rng driver hangs at
wait_for_completion_killable().
This patch fixed the hang by completing have_data completion
3.16 (guest hangs with two rng devices)
3.16 + quick fix (can startup with two rng devices) (hotplug issue 1 + hotplug
issue 2 exist)
lates torvalds/linux.git + amit 4 patches (can startup with two rng devices)
(only hotplug issue 2 exists)
However, the 4 patches also fixed the hang issue, the
When we try to hot-remove a busy virtio-rng device from QEMU monitor,
the device can't be hot-removed. Because virtio-rng driver hangs at
wait_for_completion_killable().
This patch fixed the hang by completing have_data completion before
unregistering a virtio-rng device.
Signed-off-by: Amos
On Tue, Aug 05, 2014 at 06:28:54PM +0800, Amos Kong wrote:
3.16 (guest hangs with two rng devices)
3.16 + quick fix (can startup with two rng devices) (hotplug issue 1 +
hotplug issue 2 exist)
lates torvalds/linux.git + amit 4 patches (can startup with two rng devices)
(only hotplug issue 2
QEMU commandline:
./x86_64-softmmu/qemu-system-x86_64 --enable-kvm -m 2000 -drive
file=/images/nolvm.qcow2 --kernel /home/devel/linux/arch/x86/boot/bzImage
-append ro root=/dev/sda1 console=ttyS0,115200 -monitor
unix:/tmp/m,nowait,server -device
On Mon, Jul 28, 2014 at 01:25:14PM +0530, Amit Shah wrote:
On (Mon) 28 Jul 2014 [15:32:42], Amos Kong wrote:
QEMU commandline:
./x86_64-softmmu/qemu-system-x86_64 --enable-kvm -m 2000 -drive
file=/images/nolvm.qcow2 --kernel /home/devel/linux/arch/x86/boot/bzImage
-append ro root
On Mon, Jul 28, 2014 at 02:42:13PM +0530, Amit Shah wrote:
On (Mon) 28 Jul 2014 [16:49:20], Amos Kong wrote:
On Mon, Jul 28, 2014 at 01:25:14PM +0530, Amit Shah wrote:
On (Mon) 28 Jul 2014 [15:32:42], Amos Kong wrote:
QEMU commandline:
./x86_64-softmmu/qemu-system-x86_64
On Sat, Apr 19, 2014 at 12:08:15PM +0800, Amos Kong wrote:
Hi all,
I'm working on this item in Upstream Networking todolist:
| - Sharing config interrupts
|Support more devices by sharing a single msi vector
|between multiple virtio devices.
|(Applies to virtio-blk too
On Sun, Apr 27, 2014 at 06:03:04PM +0300, Michael S. Tsirkin wrote:
On Sun, Apr 27, 2014 at 10:35:41PM +0800, Amos Kong wrote:
On Sat, Apr 19, 2014 at 12:08:15PM +0800, Amos Kong wrote:
Hi all,
I'm working on this item in Upstream Networking todolist:
| - Sharing config
On Thu, May 23, 2013 at 09:46:07AM +0200, Stefan Hajnoczi wrote:
On Wed, May 22, 2013 at 09:48:21PM +0800, Amos Kong wrote:
On Wed, May 22, 2013 at 11:32:27AM +0200, Stefan Hajnoczi wrote:
On Wed, May 22, 2013 at 12:57:35PM +0800, Amos Kong wrote:
I try to hotplug 28 * 8 multiple
for pit, pic, ioapic, coalesced_mmio. They couldn't be limited
by maximum file descriptor.
Currently only ioeventfds take too much kvm_io_bus devices,
so just exclude it from counting kvm_io_range limit.
Also fixed one indent issue in kvm_host.h
Signed-off-by: Amos Kong ak...@redhat.com
---
include
On Wed, May 22, 2013 at 11:32:27AM +0200, Stefan Hajnoczi wrote:
On Wed, May 22, 2013 at 12:57:35PM +0800, Amos Kong wrote:
I try to hotplug 28 * 8 multiple-function devices to guest with
old host kernel, ioeventfds in host kernel will be exhausted, then
qemu fails to allocate ioeventfds
I try to hotplug 28 * 8 multiple-function devices to guest with
old host kernel, ioeventfds in host kernel will be exhausted, then
qemu fails to allocate ioeventfds for blk/nic devices.
It's better to add detail error here.
Signed-off-by: Amos Kong ak...@redhat.com
---
kvm-all.c |4
1
On Mon, Jan 21, 2013 at 05:08:26PM +0100, Stefan Hajnoczi wrote:
On Sat, Jan 19, 2013 at 09:54:27AM +0800, ak...@redhat.com wrote:
@@ -350,6 +351,18 @@ static int virtio_net_handle_mac(VirtIONet *n, uint8_t
cmd,
struct virtio_net_ctrl_mac mac_data;
size_t s;
+if (cmd
buffer).
This patch makes code not rely on the layout of descriptors.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
Signed-off-by: Amos Kong ak...@redhat.com
---
hw/virtio-net.c | 128
1 file changed, 74 insertions(+), 54
This patch makes rx commands consistent with specification.
Signed-off-by: Amos Kong ak...@redhat.com
---
hw/virtio-net.c | 14 +++---
hw/virtio-net.h | 14 +++---
2 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/hw/virtio-net.c b/hw/virtio-net.c
index acef5a5
From: Michael S. Tsirkin m...@redhat.com
Virtio-net code makes assumption about virtqueue descriptor layout
(e.g. sg[0] is the header, sg[1] is the data buffer).
This patch makes code not rely on the layout of descriptors.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
Signed-off-by: Amos
new feature is acked
V4: add fix of descriptor layout assumptions, trivial rename
V5: fix endianness after iov_to_buf copy
Amos Kong (2):
virtio-net: introduce a new macaddr control
virtio-net: rename ctrl rx commands
Michael S. Tsirkin (1):
virtio-net: remove layout assumptions for ctrl vq
hardware address
V4: split eth_mac_addr, fix error handle
V5: rebase patches to net-next tree
Amos Kong (2):
move virtnet_send_command() above virtnet_set_mac_address()
virtio-net: introduce a new control to set macaddr
Stefan Hajnoczi (1):
net: split eth_mac_addr for better error handling
We want to send vq command to set mac address in
virtnet_set_mac_address(), so do this function moving.
Fixed a little issue of coding style.
Signed-off-by: Amos Kong ak...@redhat.com
---
drivers/net/virtio_net.c | 89 ++---
1 files changed, 44
,
then we can prepare first, and try to change hardware address, then do
the real commit if hardware address is set successfully.
Signed-off-by: Stefan Hajnoczi stefa...@gmail.com
Signed-off-by: Amos Kong ak...@redhat.com
---
include/linux/etherdevice.h |2 ++
net/ethernet/eth.c | 41
Currently we write MAC address to pci config space byte by byte,
this means that we have an intermediate step where mac is wrong.
This patch introduced a new control command to set MAC address,
it's atomic.
VIRTIO_NET_F_CTRL_MAC_ADDR is a new feature bit for compatibility.
Signed-off-by: Amos
On Fri, Jan 18, 2013 at 12:00:42PM +0100, Stefan Hajnoczi wrote:
On Thu, Jan 17, 2013 at 06:40:12PM +0800, ak...@redhat.com wrote:
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 395ab4f..837c978 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
Signed-off-by: Amos Kong ak...@redhat.com
---
hw/virtio-net.c | 128
1 file changed, 74 insertions(+), 54 deletions(-)
Had tested this patch with following scenarios
On Thu, Jan 17, 2013 at 01:45:11PM +0800, Amos Kong wrote:
On Thu, Jan 17, 2013 at 11:49:20AM +1030, Rusty Russell wrote:
ak...@redhat.com writes:
@@ -349,6 +351,14 @@ static int virtio_net_handle_mac(VirtIONet *n,
uint8_t cmd,
{
struct virtio_net_ctrl_mac mac_data
On Thu, Jan 17, 2013 at 02:13:08PM +0200, Michael S. Tsirkin wrote:
On Thu, Jan 17, 2013 at 11:49:20AM +1030, Rusty Russell wrote:
ak...@redhat.com writes:
@@ -349,6 +351,14 @@ static int virtio_net_handle_mac(VirtIONet *n,
uint8_t cmd,
{
struct virtio_net_ctrl_mac mac_data;
On Wed, Jan 16, 2013 at 02:20:39PM +0800, Jason Wang wrote:
On Wednesday, January 16, 2013 01:57:01 PM ak...@redhat.com wrote:
From: Amos Kong ak...@redhat.com
Currently we write MAC address to pci config space byte by byte,
this means that we have an intermediate step where mac is wrong
On Thu, Jan 17, 2013 at 11:49:20AM +1030, Rusty Russell wrote:
ak...@redhat.com writes:
@@ -349,6 +351,14 @@ static int virtio_net_handle_mac(VirtIONet *n, uint8_t
cmd,
{
struct virtio_net_ctrl_mac mac_data;
+if (cmd == VIRTIO_NET_CTRL_MAC_ADDR_SET elem-out_num == 2
+
On Wed, Jan 16, 2013 at 11:22:23AM +0200, Michael S. Tsirkin wrote:
On Wed, Jan 16, 2013 at 10:13:28AM +0100, Stefan Hajnoczi wrote:
On Wed, Jan 16, 2013 at 03:33:24PM +0800, ak...@redhat.com wrote:
+\change_inserted -1930653948 1358320004
+The command VIRTIO_NET_CTRL_MAC_ADDR_SET is used
On Thu, Jan 10, 2013 at 10:57:05PM +0800, Jason Wang wrote:
On 01/10/2013 10:45 PM, ak...@redhat.com wrote:
From: Amos Kong ak...@redhat.com
Currently we write MAC address to pci config space byte by byte,
this means that we have an intermediate step where mac is wrong.
This patch
On Thu, Jan 10, 2013 at 10:45:39PM +0800, ak...@redhat.com wrote:
From: Amos Kong ak...@redhat.com
Currenly mac is programmed byte by byte. This means that we
have an intermediate step where mac is wrong.
Second patch introduced a new vq control command to set mac
address in one time.
I
+ 63) / 64];
};
-/* ppc -- see arch/powerpc/include/asm/kvm.h */
+/* ppc -- see arch/powerpc/include/uapi/asm/kvm.h */
Trivial fix.
Reviewed-by: Amos Kong kongjian...@gmail.com
interrupt_bitmap is a bitmap of pending external interrupts. At most
one bit may be set. This interrupt has been
+ 63) / 64];
};
-/* ppc -- see arch/powerpc/include/asm/kvm.h */
+/* ppc -- see arch/powerpc/include/uapi/asm/kvm.h */
Trivial fix.
Reviewed-by: Amos Kong kongjian...@gmail.com
interrupt_bitmap is a bitmap of pending external interrupts. At most
one bit may be set. This interrupt has been
= boot,
-.type = QEMU_OPT_BOOL,
-.help = (deprecated, ignored),
},
{ /* end of list */ }
},
Reviewed-by: Amos Kong ak...@redhat.com
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord
- Original Message -
On Thu, Sep 20, 2012 at 09:46:41AM -0300, Marcelo Tosatti wrote:
On Thu, Sep 20, 2012 at 01:55:20PM +0530, Amit Shah wrote:
Commit f349c12c0434e29c79ecde89029320c4002f7253 added the guest
stop
In commitlog of f349c12c0434e29c79ecde89029320c4002f7253:
##
1 - 100 of 392 matches
Mail list logo
