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 re
't go through the 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..704a05f
- 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
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
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
d
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 al
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);
+ /
AC address 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
---
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
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/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
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
et 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
AC address 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
---
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
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
---
driver
yed(sq->vq))) {
/* 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,
La
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 with
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
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
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
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
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 pendi
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 at
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 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.
On the
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
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
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
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
- 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: v
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
virtio-rng, at a cost of a copy,
I have some patches (somewhere) 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 Lauren
?)
Thanks,
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, Michae
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 "-device
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 insertion
_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 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/2020 23:34
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
--
.
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
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
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 change
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 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
>>>&g
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
t; };
> 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&q
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 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 +
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 d
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(-)
di
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
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,
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
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
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
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
---
drivers/gpu/drm/virtio/virtgpu_plane.c | 4
1 file changed, 4 insertions(+)
diff --git 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
Signed-off-by: Laurent Vivier
---
Note: this patch has been actually written by Gerd,
but to
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.
Glauber de Oliveira Costa wrote:
>> by doing this at kernel level, we can:
>> - measure exactly the guest time,
>> - move this part of system time to user time (as you think it should be
>> user time),
>> - have consistency between system, user and guest time,
>> - report values in /proc/state and
> 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//state this value by process
> > - allow KVM to use these 3 pre
Hi John,
John Stoffel wrote:
>
> Laurent> The aim of these four patches is to introduce Virtual Machine
> Laurent> time accounting.
>
> So what does this buy us? What increased functionality?
>
functionnalities:
- allow to measure time spent by a CPU in a virtual CPU.
- allow to display in
Avi Kivity wrote:
> Laurent Vivier wrote:
>> Avi Kivity wrote:
>>
>>> Laurent Vivier wrote:
>>>
>>>> [PATCH 4/4] Modify KVM to update guest time accounting.
>>>&
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/pr
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/kv
guest and user 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-o
[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//stat to display
these new fields.
Signed-off-by: Laurent Vivi
[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/d
time. Update "gtime" and "cgtime" in signal_struct and
task_struct accordingly.
[PATCH 4/4] Modify KVM to update guest time accounting.
Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
--
- [EMAIL PROTECTED] --
"Software is h
[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: La
Avi Kivity wrote:
> Laurent Vivier wrote:
>> 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 th
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 prerequisit
Avi Kivity wrote:
> Laurent Vivier wrote:
>> KVM updates vtime in task_struct to allow account_guest_time() to modify
>> user,
>> system and guest time in cpustat accordingly.
>>
>
>> --- kvm.orig/drivers/kvm/Kconfig 2007-08-17 10:24:46.0 +0200
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
This is another way to compute guest time... I remove the "account modifiers"
mechanism and call directly account_guest_time() from account_system_time().
account_system_time() computes user, system and guest times according value
accumulated in vtime (a ktime_t) in task_struct by the virtual machi
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 +0200
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
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
>&
[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]>
--
-
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] --
[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: La
ons registered by a module to modify the
cputime value.
Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
--
- [EMAIL PROTECTED] --
"Software is hard" - Donald Knuth
Index: kvm/include/linux/sched.h
==
PATCH 2/4] like for cpustat, introduce the "guest" and "cguest" fields for the
tasks. Modify
signal_struct and task_struct. Modify /proc//stat to display these new
field
Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
--
- [EMAIL PROTECTED] ---
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 cani
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, "
88 matches
Mail list logo
