Dear maintainers, 

First of all, thank you very much for your review of my patch 
[1].

In this version (v5), I have attempted to address all the problems 
addressed by Daniel during the last review. I've been more careful with 
all the remarks made. 

However, one question remains unanswered pointing the issue with the 
location of "/var/local/run/qemu-vmsr-helper.sock", created by 
compute_default_paths(). QEMU is not allowed to reach the socket here.

Thank you again for your continued guidance. 

v4 -> v5
--------

- correct qio_channel_get_peerpid: return pid = -1 in case of error
- Vmsr_helper: compile only for x86
- Vmsr_helper: use qio_channel_read/write_all
- Vmsr_helper: abandon user/group
- Vmsr_energy.c: correct all error_report
- Vmsr thread: compute default socket path only once
- Vmsr thread: open socket only once
- Pass relevant QEMU CI

v3 -> v4
--------

- Correct memory leaks with AddressSanitizer  
- Add sanity check for QEMU and qemu-vmsr-helper for checking if host is 
  INTEL and if RAPL is activated.
- Rename poor variables naming for easier comprehension
- Move code that checks Host before creating the VMSR thread
- Get rid of libnuma: create function that read sysfs for reading the 
  Host topology instead

v2 -> v3
--------

- Move all memory allocations from Clib to Glib
- Compile on *BSD (working on Linux only)
- No more limitation on the virtual package: each vCPU that belongs to 
  the same virtual package is giving the same results like expected on 
  a real CPU.
  This has been tested topology like:
     -smp 4,sockets=2
     -smp 16,sockets=4,cores=2,threads=2

v1 -> v2
--------

- To overcome the CVE-2020-8694 a socket communication is created
  to a priviliged helper
- Add the priviliged helper (qemu-vmsr-helper)
- Add SO_PEERCRED in qio channel socket

RFC -> v1
---------

- Add vmsr_* in front of all vmsr specific function
- Change malloc()/calloc()... with all glib equivalent
- Pre-allocate all dynamic memories when possible
- Add a Documentation of implementation, limitation and usage

Best regards,
Anthony

[1]: https://lists.gnu.org/archive/html/qemu-devel/2024-03/msg04417.html

Anthony Harivel (3):
  qio: add support for SO_PEERCRED for socket channel
  tools: build qemu-vmsr-helper
  Add support for RAPL MSRs in KVM/Qemu

 accel/kvm/kvm-all.c                      |  27 ++
 contrib/systemd/qemu-vmsr-helper.service |  15 +
 contrib/systemd/qemu-vmsr-helper.socket  |   9 +
 docs/specs/index.rst                     |   1 +
 docs/specs/rapl-msr.rst                  | 155 +++++++
 docs/tools/index.rst                     |   1 +
 docs/tools/qemu-vmsr-helper.rst          |  89 ++++
 include/io/channel.h                     |  21 +
 include/sysemu/kvm.h                     |   2 +
 include/sysemu/kvm_int.h                 |  32 ++
 io/channel-socket.c                      |  28 ++
 io/channel.c                             |  13 +
 meson.build                              |   7 +
 target/i386/cpu.h                        |   8 +
 target/i386/kvm/kvm-cpu.c                |   9 +
 target/i386/kvm/kvm.c                    | 428 ++++++++++++++++++
 target/i386/kvm/meson.build              |   1 +
 target/i386/kvm/vmsr_energy.c            | 335 ++++++++++++++
 target/i386/kvm/vmsr_energy.h            |  99 +++++
 tools/i386/qemu-vmsr-helper.c            | 529 +++++++++++++++++++++++
 tools/i386/rapl-msr-index.h              |  28 ++
 21 files changed, 1837 insertions(+)
 create mode 100644 contrib/systemd/qemu-vmsr-helper.service
 create mode 100644 contrib/systemd/qemu-vmsr-helper.socket
 create mode 100644 docs/specs/rapl-msr.rst
 create mode 100644 docs/tools/qemu-vmsr-helper.rst
 create mode 100644 target/i386/kvm/vmsr_energy.c
 create mode 100644 target/i386/kvm/vmsr_energy.h
 create mode 100644 tools/i386/qemu-vmsr-helper.c
 create mode 100644 tools/i386/rapl-msr-index.h

-- 
2.44.0

On Thu, Apr 11, 2024 at 02:14:31PM +0200, Anthony Harivel wrote:
> Dear maintainers, 
> 
> First of all, thank you very much for your review of my patch 
> [1].
> 
> In this version (v5), I have attempted to address all the problems 
> addressed by Daniel during the last review. I've been more careful with 
> all the remarks made.

I'm wondering if you had tips for testing this functionality ?

Is there any nice app to run in the host/guest to report the
power usage, to see that it is working as desired ?


With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Hi Daniel,

Daniel P. Berrangé, Apr 17, 2024 at 19:23:
> On Thu, Apr 11, 2024 at 02:14:31PM +0200, Anthony Harivel wrote:
> > Dear maintainers, 
> > 
> > First of all, thank you very much for your review of my patch 
> > [1].
> > 
> > In this version (v5), I have attempted to address all the problems 
> > addressed by Daniel during the last review. I've been more careful with 
> > all the remarks made.
>
> I'm wondering if you had tips for testing this functionality ?
>
> Is there any nice app to run in the host/guest to report the
> power usage, to see that it is working as desired ?
>

Great question. Unfortunately, there isn't an easy-to-use, 
out-of-the-box app that can assist you.

The 'cpupower' tool in linux/tools/power/ or 'turbostat' in 
linux/tools/power/x86/ require some modifications as they fail the 
sanity check inside a VM. It is on my agenda to work on a proposal patch 
for these tools if the vmsr patch lands in QEMU. These are the excellent 
apps that everyone should use IMO.

So how do I test my patch ? 
I'm using a slightly more complex tool called Kepler [1]. Since a patch 
that has been merged [2], it can also report VM consumption.
The installation is easy on RPM based distribution [3].
But indeed, this tools is a Prometheus exporter so you need 
a Prometheus/Grafana stack for the observation which make the test more 
complex than the 2 previous tools mentioned.

Last month, I conducted a test with Kepler tools on both a host and 
within VMs. I was pleased to observe that the power graph trends were 
identical both outside and inside the VMs, albeit with a slight 
variation in terms of 1:1 Watt comparison.

If Kepler isn't the tool you're looking for, I'm open to any suggestions 
regarding cpupower/turbostat. I can work on a temporary patch that would 
enable us to utilize them.

Regards,
Anthony

[1]: https://sustainable-computing.io/
[2]: https://github.com/sustainable-computing-io/kepler/pull/931
[3]: https://sustainable-computing.io/installation/kepler-rpm/

On Thu, Apr 11, 2024 at 2:14 PM Anthony Harivel <aharivel@redhat.com> wrote:
>
> Dear maintainers,
>
> First of all, thank you very much for your review of my patch
> [1].
>
> In this version (v5), I have attempted to address all the problems
> addressed by Daniel during the last review. I've been more careful with
> all the remarks made.
>
> However, one question remains unanswered pointing the issue with the
> location of "/var/local/run/qemu-vmsr-helper.sock", created by
> compute_default_paths(). QEMU is not allowed to reach the socket here.

If I understand correctly the question, that is expected. This is a
privileged functionality and therefore it requires manual intervention
to change the owner of the socket and allow QEMU to access it.

Paolo

> Thank you again for your continued guidance.
>
> v4 -> v5
> --------
>
> - correct qio_channel_get_peerpid: return pid = -1 in case of error
> - Vmsr_helper: compile only for x86
> - Vmsr_helper: use qio_channel_read/write_all
> - Vmsr_helper: abandon user/group
> - Vmsr_energy.c: correct all error_report
> - Vmsr thread: compute default socket path only once
> - Vmsr thread: open socket only once
> - Pass relevant QEMU CI
>
> v3 -> v4
> --------
>
> - Correct memory leaks with AddressSanitizer
> - Add sanity check for QEMU and qemu-vmsr-helper for checking if host is
>   INTEL and if RAPL is activated.
> - Rename poor variables naming for easier comprehension
> - Move code that checks Host before creating the VMSR thread
> - Get rid of libnuma: create function that read sysfs for reading the
>   Host topology instead
>
> v2 -> v3
> --------
>
> - Move all memory allocations from Clib to Glib
> - Compile on *BSD (working on Linux only)
> - No more limitation on the virtual package: each vCPU that belongs to
>   the same virtual package is giving the same results like expected on
>   a real CPU.
>   This has been tested topology like:
>      -smp 4,sockets=2
>      -smp 16,sockets=4,cores=2,threads=2
>
> v1 -> v2
> --------
>
> - To overcome the CVE-2020-8694 a socket communication is created
>   to a priviliged helper
> - Add the priviliged helper (qemu-vmsr-helper)
> - Add SO_PEERCRED in qio channel socket
>
> RFC -> v1
> ---------
>
> - Add vmsr_* in front of all vmsr specific function
> - Change malloc()/calloc()... with all glib equivalent
> - Pre-allocate all dynamic memories when possible
> - Add a Documentation of implementation, limitation and usage
>
> Best regards,
> Anthony
>
> [1]: https://lists.gnu.org/archive/html/qemu-devel/2024-03/msg04417.html
>
> Anthony Harivel (3):
>   qio: add support for SO_PEERCRED for socket channel
>   tools: build qemu-vmsr-helper
>   Add support for RAPL MSRs in KVM/Qemu
>
>  accel/kvm/kvm-all.c                      |  27 ++
>  contrib/systemd/qemu-vmsr-helper.service |  15 +
>  contrib/systemd/qemu-vmsr-helper.socket  |   9 +
>  docs/specs/index.rst                     |   1 +
>  docs/specs/rapl-msr.rst                  | 155 +++++++
>  docs/tools/index.rst                     |   1 +
>  docs/tools/qemu-vmsr-helper.rst          |  89 ++++
>  include/io/channel.h                     |  21 +
>  include/sysemu/kvm.h                     |   2 +
>  include/sysemu/kvm_int.h                 |  32 ++
>  io/channel-socket.c                      |  28 ++
>  io/channel.c                             |  13 +
>  meson.build                              |   7 +
>  target/i386/cpu.h                        |   8 +
>  target/i386/kvm/kvm-cpu.c                |   9 +
>  target/i386/kvm/kvm.c                    | 428 ++++++++++++++++++
>  target/i386/kvm/meson.build              |   1 +
>  target/i386/kvm/vmsr_energy.c            | 335 ++++++++++++++
>  target/i386/kvm/vmsr_energy.h            |  99 +++++
>  tools/i386/qemu-vmsr-helper.c            | 529 +++++++++++++++++++++++
>  tools/i386/rapl-msr-index.h              |  28 ++
>  21 files changed, 1837 insertions(+)
>  create mode 100644 contrib/systemd/qemu-vmsr-helper.service
>  create mode 100644 contrib/systemd/qemu-vmsr-helper.socket
>  create mode 100644 docs/specs/rapl-msr.rst
>  create mode 100644 docs/tools/qemu-vmsr-helper.rst
>  create mode 100644 target/i386/kvm/vmsr_energy.c
>  create mode 100644 target/i386/kvm/vmsr_energy.h
>  create mode 100644 tools/i386/qemu-vmsr-helper.c
>  create mode 100644 tools/i386/rapl-msr-index.h
>
> --
> 2.44.0
>

On Fri, Apr 12, 2024 at 12:57:11PM +0200, Paolo Bonzini wrote:
> On Thu, Apr 11, 2024 at 2:14 PM Anthony Harivel <aharivel@redhat.com> wrote:
> >
> > Dear maintainers,
> >
> > First of all, thank you very much for your review of my patch
> > [1].
> >
> > In this version (v5), I have attempted to address all the problems
> > addressed by Daniel during the last review. I've been more careful with
> > all the remarks made.
> >
> > However, one question remains unanswered pointing the issue with the
> > location of "/var/local/run/qemu-vmsr-helper.sock", created by
> > compute_default_paths(). QEMU is not allowed to reach the socket here.
> 
> If I understand correctly the question, that is expected. This is a
> privileged functionality and therefore it requires manual intervention
> to change the owner of the socket and allow QEMU to access it.

In the systemd case, it will set the owner and mode, but in the
non-system case, I wonder if it worth making this helper program
have "--socket-owner" and "--socket-mode" args, so it can create
the socket with the right mode/owner immediately, rather than
expecting the admin to manuall chmod+chown after start the
helper


With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

On Wed, Apr 17, 2024 at 7:58 PM Daniel P. Berrangé <berrange@redhat.com> wrote:
> > > However, one question remains unanswered pointing the issue with the
> > > location of "/var/local/run/qemu-vmsr-helper.sock", created by
> > > compute_default_paths(). QEMU is not allowed to reach the socket here.
> >
> > If I understand correctly the question, that is expected. This is a
> > privileged functionality and therefore it requires manual intervention
> > to change the owner of the socket and allow QEMU to access it.
>
> In the systemd case, it will set the owner and mode, but in the
> non-system case, I wonder if it worth making this helper program
> have "--socket-owner" and "--socket-mode" args, so it can create
> the socket with the right mode/owner immediately, rather than
> expecting the admin to manuall chmod+chown after start the
> helper

I think a better idea would be to contribute them to
systemd-socket-activate, and just launch the helper that way. It's
mostly a testing tool, but tbh if you're not using systemd you're on
your own. If you write an init script for example, that would be the
place where you put the chmod/chown.

Paolo