Avi Kivity wrote:
Laurent Vivier wrote:
The aim of these two patches is to measure the CPU time used by a virtual
machine. All comments are welcome... I'm not sure it's the good way to
do that.
[PATCH 1/2] introduce a new field, guest, in cpustat to store the
time used by
the CPU to run
Avi Kivity wrote:
Laurent Vivier wrote:
- perhaps the new fields should be guarded by a #ifdef CONFIG_HYPERVISOR
(selected by CONFIG_KVM)? that way the (minor) additional overhead is
only incurred if it can possibly be used. I imagine that our canine
cousin will want to use this as well
value.
Signed-off-by: Laurent Vivier [EMAIL PROTECTED]
--
- [EMAIL PROTECTED] --
Software is hard - Donald Knuth
Index: kvm/include/linux/sched.h
===
--- kvm.orig/include/linux/sched.h 2007-08
[PATCH 1/4] as modern CPUs introduce a third running state, after user and
system, we need a new field, guest, in cpustat to store the time used by
the CPU to run virtual CPU. Modify /proc/stat to display this new field.
Signed-off-by: Laurent Vivier [EMAIL PROTECTED]
--
- [EMAIL
[PATCH 4/4] Modify KVM to use the account modifiers. KVM can now measure time
consumed by a Virtual Machine on a per-cpu basis and modify kernel statistics to
report this value.
Signed-off-by: Laurent Vivier [EMAIL PROTECTED]
--
- [EMAIL PROTECTED] --
Software
Rusty Russell wrote:
On Thu, 2007-08-16 at 17:58 +0200, Laurent Vivier wrote:
[PATCH 3/3] introduce account modifiers mechanism in the kernel allowing a
module to modify the collected accounting for a given task. This
implementation
is based on the preempt_notifier. account_system_time
Rusty Russell wrote:
On Fri, 2007-08-17 at 09:35 +0200, Laurent Vivier wrote:
Rusty Russell wrote:
Hi Laurent,
Hi Rusty,
how are your puppies ?
They're getting a little fat, actually. Too many features ...
- remove PATCH 3, and add in task_struct a ktime vtime where we accumulate
KVM updates vtime in task_struct to allow account_guest_time() to modify user,
system and guest time in cpustat accordingly.
Index: kvm/drivers/kvm/Kconfig
===
--- kvm.orig/drivers/kvm/Kconfig2007-08-17 10:24:46.0
Avi Kivity wrote:
Laurent Vivier wrote:
- remove PATCH 3, and add in task_struct a ktime vtime where we
accumulate
guest time (by calling something like guest_enter() and guest_exit() from
the
virtualization engine), and when in account_system_time() we have cputime
vtime we
Avi Kivity wrote:
[...]
The normal user/system accounting has the same issue, no? Whereever we
happen to land (kernel or user) gets the whole tick.
So I think it is okay to have the same limitation for guest time.
So this is how it looks like.
PATCH 1 and 2 are always a prerequisite.
[PATCH 1/4] as recent CPUs introduce a third running state, after user and
system, we need a new field, guest, in cpustat to store the time used by
the CPU to run virtual CPU. Modify /proc/stat to display this new field.
Signed-off-by: Laurent Vivier [EMAIL PROTECTED]
--
- [EMAIL
] Modify KVM to update guest time accounting.
Signed-off-by: Laurent Vivier [EMAIL PROTECTED]
--
- [EMAIL PROTECTED] --
Software is hard - Donald Knuth
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
[PATCH 4/4] Modify KVM to update guest time accounting.
Signed-off-by: Laurent Vivier [EMAIL PROTECTED]
--
- [EMAIL PROTECTED] --
Software is hard - Donald Knuth
Index: kvm/drivers/kvm/kvm.h
[PATCH 2/4] like for cpustat, introduce the gtime (guest time of the task) and
cgtime (guest time of the task children) fields for the
tasks. Modify signal_struct and task_struct. Modify /proc/pid/stat to display
these new fields.
Signed-off-by: Laurent Vivier [EMAIL PROTECTED
to
allow an unmodified top(1) to display correct value. A modified top(1) is
able to display good cpu user time and cpu guest time by subtracting cpu guest
time from cpu user time. Update gtime in task_struct accordingly.
Signed-off-by: Laurent Vivier [EMAIL PROTECTED]
--
- [EMAIL
Avi Kivity wrote:
Laurent Vivier wrote:
[PATCH 4/4] Modify KVM to update guest time accounting.
Index: kvm/drivers/kvm/kvm.h
===
--- kvm.orig/drivers/kvm/kvm.h2007-08-20 13:23:53.0 +0200
+++ kvm/drivers/kvm
Christian Borntraeger wrote:
Am Montag, 20. August 2007 schrieb Laurent Vivier:
Index: kvm/fs/proc/array.c
===
--- kvm.orig/fs/proc/array.c2007-08-20 11:11:30.0 +0200
+++ kvm/fs/proc/array.c 2007-08-20 13:04
Avi Kivity wrote:
Laurent Vivier wrote:
Avi Kivity wrote:
Laurent Vivier wrote:
[PATCH 4/4] Modify KVM to update guest time accounting.
Index: kvm/drivers/kvm/kvm.h
===
--- kvm.orig/drivers/kvm/kvm.h
Laurent Vivier wrote:
functionnalities:
- allow to measure time spent by a CPU in a virtual CPU.
- allow to display in /proc/state this value by CPU
- allow to display in /proc/pid/state this value by process
- allow KVM to use these 3 previous functionnalities
So, currently time
On 09/07/2015 09:49, Thomas Huth wrote:
The option for supporting cross-endianness legacy guests in
the vhost and tun code should only be available on systems
that support cross-endian guests.
I'm sure I misunderstand something, but what happens if we use QEMU with
TCG instead of KVM, i.e. a
VIRTIO_GPU_F_VIRGL is added in features list only
for LE kernel, so we must check for it only on LE kernel,
otherwise virtio_has_feature() calls BUG() and
crashes the kernel.
Suggested-by: Gerd Hoffmann <kra...@redhat.com>
Signed-off-by: Laurent Vivier <lviv...@redhat.com>
---
Note
When we use virtio-vga with a big-endian guest,
the mouse pointer disappears.
To fix that, on big-endian use DRM_FORMAT_BGRA
instead of DRM_FORMAT_ARGB.
Signed-off-by: Laurent Vivier <lviv...@redhat.com>
---
drivers/gpu/drm/virtio/virtgpu_plane.c | 4
1 file changed, 4 inse
On 05/04/2017 19:11, Ville Syrjälä wrote:
> On Wed, Apr 05, 2017 at 10:09:15AM +0200, Laurent Vivier wrote:
>> When we use virtio-vga with a big-endian guest,
>> the mouse pointer disappears.
>>
>> To fix that, on big-endian use DRM_FORMAT_BGRA
>> instead of
Any comments?
Thanks,
Laurent
On 18/10/2019 18:47, Laurent Vivier wrote:
> When we hot unplug a virtserialport and then try to hot plug again,
> it fails:
>
> (qemu) chardev-add socket,id=serial0,path=/tmp/serial0,server,nowait
> (qemu) device_add virtserialport,bus=virtio
On 06/11/2019 16:03, Michael S. Tsirkin wrote:
> On Wed, Nov 06, 2019 at 03:02:25PM +0100, Laurent Vivier wrote:
>> On 06/11/2019 14:56, Michael S. Tsirkin wrote:
>>> On Fri, Oct 18, 2019 at 06:47:18PM +0200, Laurent Vivier wrote:
>>>> When we hot unplug a virtseria
On 06/11/2019 14:56, Michael S. Tsirkin wrote:
> On Fri, Oct 18, 2019 at 06:47:18PM +0200, Laurent Vivier wrote:
>> When we hot unplug a virtserialport and then try to hot plug again,
>> it fails:
>>
>> (qemu) chardev-add socket,id=serial0,path=/tmp/serial0,server,
On 13/11/2019 16:22, Michael S. Tsirkin wrote:
> On Wed, Nov 13, 2019 at 10:21:11AM -0500, Michael S. Tsirkin wrote:
>> On Wed, Nov 13, 2019 at 04:00:56PM +0100, Laurent Vivier wrote:
>>> When we hot unplug a virtserialport and then try to hot plug again,
>>> it fails:
om
Cc: sta...@vger.kernel.org
Signed-off-by: Laurent Vivier
---
Notes:
v2: making fill_queue return int and testing return code for -ENOSPC
drivers/char/virtio_console.c | 24 +---
1 file changed, 9 insertions(+), 15 deletions(-)
diff --git a/drivers/char/virtio_console.c b/dr
() as they are released in remove_vqs(), but it sounds like
a waste of memory.
Rather than that, this patch changes add_port() logic to only allocate the
buffers if the in_vq has available free slots.
Fixes: a7a69ec0d8e4 ("virtio_console: free buffers after reset")
Cc: m...@redhat.com
Signed-off-by: Laur
om
Cc: sta...@vger.kernel.org
Signed-off-by: Laurent Vivier
---
Notes:
v3: add a comment about ENOSPC error
v2: making fill_queue return int and testing return code for -ENOSPC
drivers/char/virtio_console.c | 28 +---
1 file changed, 13 insertions(+), 15 deletions(-)
On 28/08/2020 23:34, Martin Wilck wrote:
> On Wed, 2020-08-26 at 08:26 -0400, Michael S. Tsirkin wrote:
>> On Tue, Aug 11, 2020 at 04:42:32PM +0200, Laurent Vivier wrote:
>>> On 11/08/2020 16:28, mwi...@suse.com wrote:
>>>> From: Martin Wilck
>>&
xpected TXQ (0) queue failure: -12
Fixes: 2c53d0f64c06 ("vdpasim: vDPA device simulator")
Signed-off-by: Laurent Vivier
---
drivers/vdpa/vdpa_sim/vdpa_sim.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c b/drivers/vdpa/vdpa_sim/vdpa_s
On 11/08/2020 16:49, Michael S. Tsirkin wrote:
> On Tue, Aug 11, 2020 at 03:53:54PM +0200, Laurent Vivier wrote:
>> On 11/08/2020 15:14, Michael S. Tsirkin wrote:
>>> On Tue, Aug 11, 2020 at 03:00:14PM +0200, Laurent Vivier wrote:
>>>> No problem. This code is tricky
On 11/08/2020 14:22, Martin Wilck wrote:
> On Tue, 2020-08-11 at 14:02 +0200, Laurent Vivier wrote:
>>
>>>> drivers/char/hw_random/virtio-rng.c | 14 ++
>>>> 1 file changed, 14 insertions(+)
>>>>
>>>> diff --git a/drivers/
On 11/08/2020 12:37, Philippe Mathieu-Daudé wrote:
> You Cc'ed qemu-devel, so Cc'ing the virtio-rng maintainers.
>
> On 7/15/20 3:32 PM, mwi...@suse.com wrote:
>> From: Martin Wilck
>>
>> If a program opens /dev/hwrng with O_NONBLOCK and uses poll() and
>> non-blocking read() to retrieve random
On 11/08/2020 14:53, Martin Wilck wrote:
> On Tue, 2020-08-11 at 14:39 +0200, Laurent Vivier wrote:
>> On 11/08/2020 14:22, Martin Wilck wrote:
>>> On Tue, 2020-08-11 at 14:02 +0200, Laurent Vivier wrote:
>>>>>> drivers/char/hw_random/virtio-rng.c | 14 +
};
> loop(fd);
> close(fd);
> return 0;
> }
>
> This can be observed in the real word e.g. with nested qemu/KVM virtual
> machines, if both the "outer" and "inner" VMs have a virtio-rng device.
> If the "inner" VM requests
On 11/08/2020 15:14, Michael S. Tsirkin wrote:
> On Tue, Aug 11, 2020 at 03:00:14PM +0200, Laurent Vivier wrote:
>> No problem. This code is tricky and it took me several months to really
>> start to understand it ...
>
> Oh great, we actually have someone who understands
On 25/11/2020 10:39, Michael S. Tsirkin wrote:
> On Tue, Sep 08, 2020 at 05:33:40PM +0200, Martin Wilck wrote:
>> On Tue, 2020-09-08 at 10:14 -0400, Michael S. Tsirkin wrote:
>>> On Mon, Aug 31, 2020 at 02:37:26PM +0200, Laurent Vivier wrote:
>>>> On 28/08/
ERROR: modpost: "mac_pton" [drivers/vdpa/vdpa_sim/vdpa_sim.ko] undefined!
mac_pton() is defined in lib/net_utils.c and is not built if NET is not set.
Select GENERIC_NET_UTILS as vdpasim doesn't depend on NET.
Reported-by: kernel test robot
Signed-off-by: Laurent Vivier
---
dr
Add macaddr parameter to the module to set the MAC address to use
Signed-off-by: Laurent Vivier
---
drivers/vdpa/vdpa_sim/vdpa_sim.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c b/drivers/vdpa/vdpa_sim/vdpa_sim.c
index
.
Fix that by adding VIRTIO_NET_F_MAC in the features list of vdpa_sim.
Fixes: 2c53d0f64c06 ("vdpasim: vDPA device simulator")
Cc: jasow...@redhat.com
Signed-off-by: Laurent Vivier
---
drivers/vdpa/vdpa_sim/vdpa_sim.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
the user to
set the MAC address. With that we use vdpa_sim with a stable
MAC addres, that doesn't change between reboots.
Laurent Vivier (2):
vdpasim: fix MAC address configuration
vdpasim: allow to assign a MAC address
drivers/vdpa/vdpa_sim/vdpa_sim.c | 17 +++--
1 file changed, 15
ser_be is used before being set.
To fix that, reverse the lines order as there is no other dependency
between them.
Signed-off-by: Laurent Vivier
---
drivers/vhost/vhost.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index a262e1
On 15/03/2021 17:34, Stefano Garzarella wrote:
> This new helper returns the total number of bytes covered by
> a vringh_kiov.
>
> Suggested-by: Jason Wang
> Acked-by: Jason Wang
> Signed-off-by: Stefano Garzarella
> ---
> include/linux/vringh.h | 11 +++
> 1 file changed, 11
On 19/08/2021 22:58, Michael S. Tsirkin wrote:
> On Fri, Nov 13, 2020 at 06:26:16PM +0100, Alexander Potapenko wrote:
>> Hi Amos, Rusty, Amit, Michael,
>>
>> I am hitting something that I believe to be a minor problem in the
>> virtio RNG driver.
>> When running the kernel under KMSAN with
,
Laurent
> Thanks,
> Alex
>
> On Fri, Aug 20, 2021 at 6:15 PM Laurent Vivier wrote:
>>
>> On 19/08/2021 22:58, Michael S. Tsirkin wrote:
>>> On Fri, Nov 13, 2020 at 06:26:16PM +0100, Alexander Potapenko wrote:
>>>> Hi Amos, Rusty, Amit, Michael,
>>
here) I can refresh to do that.
3- modify hw_random/core.c to use only one buffer
Thanks,
Laurent
[1] 78887832e765 ("hwrng: core - don't wait on add_early_randomness()")
HTH,
Alex
On Mon, Sep 13, 2021 at 8:52 AM Laurent Vivier wrote:
Hi Alexander,
On 12/09/2021 19:05, Alexander
On 17/09/2021 00:58, Michael S. Tsirkin wrote:
On Thu, Sep 16, 2021 at 10:52:59AM +0200, Laurent Vivier wrote:
On 13/09/2021 10:25, Alexander Potapenko wrote:
Hi Laurent,
I took the latest kernel (5.15-rc1,
6880fa6c56601bb8ed59df6c30fd390cc5f6dd8f) and a slightly modified
config from syzbot
On 23/09/2021 09:04, Michael S. Tsirkin wrote:
On Thu, Sep 23, 2021 at 08:26:06AM +0200, Laurent Vivier wrote:
On 22/09/2021 21:02, Michael S. Tsirkin wrote:
On Wed, Sep 22, 2021 at 07:09:00PM +0200, Laurent Vivier wrote:
hwrng core uses two buffers that can be mixed in the
virtio-rng queue
On 22/09/2021 21:02, Michael S. Tsirkin wrote:
On Wed, Sep 22, 2021 at 07:09:00PM +0200, Laurent Vivier wrote:
hwrng core uses two buffers that can be mixed in the
virtio-rng queue.
If the buffer is provided with wait=0 it is enqueued in the
virtio-rng queue but unused by the caller
will be retrieve and use
when the virtio-rng driver will be selected again.
This avoids to hang on an rng_current write command if the virtio-rng
device is blocked by a lack of entropy. This allows to select
another entropy source if the current one is empty.
Signed-off-by: Laurent Vivier
if we don't use all the entropy available in the buffer, keep it
and use it later.
Signed-off-by: Laurent Vivier
---
drivers/char/hw_random/virtio-rng.c | 52 +++--
1 file changed, 35 insertions(+), 17 deletions(-)
diff --git a/drivers/char/hw_random/virtio-rng.c
b
If we ensure we have already some data available by enqueuing
again the buffer once data are exhausted, we can return what we
have without waiting for the device answer.
Signed-off-by: Laurent Vivier
---
drivers/char/hw_random/virtio-rng.c | 24 ++--
1 file changed, 10
- actually returns some data when wait=0 as we can have some already
available data
It also tries to improve the performance by always having a buffer in
the queue of the device.
Laurent Vivier (4):
hwrng: virtio - add an internal buffer
hwrng: virtio - don't wait on cleanup
hwrng: virtio
reads the data from the new one that is not
updated, and the data in the first one are lost.
To avoid this mix, virtio-rng needs to use its own unique
internal buffer at a cost of a data copy to the caller buffer.
Signed-off-by: Laurent Vivier
---
drivers/char/hw_random/virtio-rng.c | 43
On 22/09/2021 19:08, Laurent Vivier wrote:
hwrng core uses two buffers that can be mixed in the virtio-rng queue.
This series fixes the problem by adding an internal buffer in virtio-rng.
Once the internal buffer is added, we can fix two other problems:
- to be able to release the driver
On 05/10/2021 13:55, Michael S. Tsirkin wrote:
On Thu, Sep 23, 2021 at 09:34:18AM +0200, Laurent Vivier wrote:
On 23/09/2021 09:04, Michael S. Tsirkin wrote:
On Thu, Sep 23, 2021 at 08:26:06AM +0200, Laurent Vivier wrote:
On 22/09/2021 21:02, Michael S. Tsirkin wrote:
On Wed, Sep 22, 2021
reads the data from the new one that is not
updated, and the data in the first one are lost.
To avoid this mix, virtio-rng needs to use its own unique
internal buffer at a cost of a data copy to the caller buffer.
Signed-off-by: Laurent Vivier
---
drivers/char/hw_random/virtio-rng.c | 43
will be retrieve and use
when the virtio-rng driver will be selected again.
This avoids to hang on an rng_current write command if the virtio-rng
device is blocked by a lack of entropy. This allows to select
another entropy source if the current one is empty.
Signed-off-by: Laurent Vivier
if we don't use all the entropy available in the buffer, keep it
and use it later.
Signed-off-by: Laurent Vivier
---
drivers/char/hw_random/virtio-rng.c | 52 +++--
1 file changed, 35 insertions(+), 17 deletions(-)
diff --git a/drivers/char/hw_random/virtio-rng.c
b
If we ensure we have already some data available by enqueuing
again the buffer once data are exhausted, we can return what we
have without waiting for the device answer.
Signed-off-by: Laurent Vivier
---
drivers/char/hw_random/virtio-rng.c | 26 --
1 file changed, 12
the buffer is submitted not when it is
received as the consumer checks for data_avail, not only for the completion.
Laurent Vivier (4):
hwrng: virtio - add an internal buffer
hwrng: virtio - don't wait on cleanup
hwrng: virtio - don't waste entropy
hwrng: virtio - always add a pending request
Hi Michael,
On 5/26/21 10:24, Michael S. Tsirkin wrote:
There are currently two cases where we poll TX vq not in response to a
callback: start xmit and rx napi. We currently do this with callbacks
enabled which can cause extra interrupts from the card. Used not to be
a big issue as we run
On 1/24/23 04:31, Jakub Kicinski wrote:
On Sun, 22 Jan 2023 15:47:08 +0200 Eli Cohen wrote:
@@ -3956,6 +3958,18 @@ static int virtnet_probe(struct virtio_device *vdev)
pr_debug("virtnet: registered device %s with %d RX and TX vq's\n",
dev->name, max_queue_pairs);
+
On 1/24/23 11:15, Michael S. Tsirkin wrote:
On Mon, Jan 23, 2023 at 01:00:22PM +0100, Laurent Vivier wrote:
In virtnet_probe(), if the device doesn't provide a MAC address the
driver assigns a random one.
As we modify the MAC address we need to notify the device to allow it
to update all
this problem, use virtnet_send_command(VIRTIO_NET_CTRL_MAC)
to set the address from virtnet_probe() when the MAC address is
not provided by the device.
v2:
- remove vdpa_sim related fixes
- check virtio_has_feature(vdev, VIRTIO_NET_F_MAC) rather than
addr_assign_type
Laurent Vivier (1
by default. The virtio_net device uses a random
MAC address (we can see it with "ip link"), but we can't ping a net
namespace from another one using the virtio-vdpa device because the
new MAC address has not been provided to the hardware.
Signed-off-by: Laurent Vivier
---
drivers/net/vi
On 1/22/23 11:23, Michael S. Tsirkin wrote:
On Sun, Jan 22, 2023 at 11:05:22AM +0100, Laurent Vivier wrote:
When the MAC address is not provided by the vdpa device virtio_net
driver assigns a random one without notifying the device.
The consequence, in the case of mlx5_vdpa, is the internal
On 1/22/23 14:47, Eli Cohen wrote:
On 22/01/2023 12:05, Laurent Vivier wrote:
In virtnet_probe(), if the device doesn't provide a MAC address the
driver assigns a random one.
As we modify the MAC address we need to notify the device to allow it
to update all the related information
On 1/31/23 10:01, Paolo Abeni wrote:
On Fri, 2023-01-27 at 21:45 +0100, Laurent Vivier wrote:
In virtnet_probe(), if the device doesn't provide a MAC address the
driver assigns a random one.
As we modify the MAC address we need to notify the device to allow it
to update all the related
On 1/27/23 12:08, Michael S. Tsirkin wrote:
On Tue, Jan 24, 2023 at 12:04:24PM +0100, Laurent Vivier wrote:
On 1/24/23 11:15, Michael S. Tsirkin wrote:
On Mon, Jan 23, 2023 at 01:00:22PM +0100, Laurent Vivier wrote:
In virtnet_probe(), if the device doesn't provide a MAC address the
driver
he receive filters,
TX packets go through unaffected.
Signed-off-by: Laurent Vivier
---
drivers/net/virtio_net.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 7d700f8e545a..704a05f1c279 100644
--- a/d
networking/net_failover.rst
This patch disables the STANDBY feature if the MAC address is not
provided by the hypervisor.
Signed-off-by: Laurent Vivier
---
drivers/net/virtio_net.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 77
- check virtio_has_feature(vdev, VIRTIO_NET_F_MAC) rather than
addr_assign_type
Laurent Vivier (2):
virtio_net: disable VIRTIO_NET_F_STANDBY if VIRTIO_NET_F_MAC is not
set
virtio_net: notify MAC address change on device initialization
drivers/net/virtio_net.c | 26
)) {
/* More just got used, free them then recheck. */
free_old_xmit_skbs(sq, false);
if (sq->vq->num_free >= 2+MAX_SKB_FRAGS) {
This fix works fine with my test case (netdev stream + passt)
Tested-by: Laurent Vivier
Thanks,
Laurent
___
if the device control queue is buggy, don't crash the kernel by
waiting for ever the response.
Signed-off-by: Laurent Vivier
---
drivers/net/virtio_net.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index
by default. The virtio_net device uses a random
MAC address (we can see it with "ip link"), but we can't ping a net
namespace from another one using the virtio-vdpa device because the
new MAC address has not been provided to the hardware.
Signed-off-by: Laurent Vivier
---
drivers/net/vi
to process the command, replace the cpu_relax()
in the loop by a schedule(). vdpa_sim_net uses a workqueue to process
the queue, and if we don't allow the kernel to schedule, the queue
is not processed and the loop is infinite.
Laurent Vivier (4):
virtio_net: notify MAC address change on device
.
But as virtnet_send_command() uses a loop, the scheduler cannot schedule
the workqueue and the virtqueue is never processed (and the command
never executed).
To fix that, replace in the loop the cpu_relax() by a schedule().
Signed-off-by: Laurent Vivier
---
drivers/net/virtio_net.c | 2 +-
1 file changed
if vdpa dev command doesn't set a MAC address, don't report
VIRTIO_NET_F_MAC.
As vdpa_sim_net sets VIRTIO_NET_F_MAC without setting the MAC address,
virtio-net doesn't set a random one and the address appears to be the
zero MAC address.
Signed-off-by: Laurent Vivier
---
drivers/vdpa/vdpa_sim
81 matches
Mail list logo
