On Mon, Sep 02, 2024 at 03:09:42PM +0200, Peter Krempa wrote: > On Thu, Aug 22, 2024 at 17:59:47 +0200, Anthony Harivel wrote: > > Add the support in libvirt to activate the RAPL feature in QEMU. > > > > This feature is activated with -accel kvm,rapl=true,path=/path/sock.sock > > in QEMU. > > > > The feature is activated in libvirt with the following XML > > configuration: > > > > <kvm> > > [...] > > <rapl state ='on' socket='/run/qemu-vmsr-helper.sock'/> > > [...] > > </kvm> > > > > See: https://gitlab.com/qemu-project/qemu/-/commit/0418f90809aea5b375c859e744c8e8610e9be446 > > > > Signed-off-by: Anthony Harivel <aharivel@xxxxxxxxxx> > > --- > > docs/formatdomain.rst | 2 ++ > > src/conf/domain_conf.c | 18 ++++++++++++++++++ > > src/conf/domain_conf.h | 2 ++ > > src/conf/schemas/domaincommon.rng | 10 ++++++++++ > > src/qemu/qemu_command.c | 11 +++++++++++ > > tests/qemuxmlconfdata/kvm-features-off.xml | 1 + > > .../kvm-features.x86_64-latest.args | 2 +- > > tests/qemuxmlconfdata/kvm-features.xml | 1 + > > 8 files changed, 46 insertions(+), 1 deletion(-) > > [...] > > > @@ -7176,6 +7179,14 @@ qemuBuildAccelCommandLine(virCommand *cmd, > > def->kvm_features->features[VIR_DOMAIN_KVM_DIRTY_RING] == VIR_TRISTATE_SWITCH_ON) { > > virBufferAsprintf(&buf, ",dirty-ring-size=%d", def->kvm_features->dirty_ring_size); > > } > > This should be separated via a newline. > > > + if (def->features[VIR_DOMAIN_FEATURE_KVM] == VIR_TRISTATE_SWITCH_ON && > > + def->kvm_features->features[VIR_DOMAIN_KVM_RAPL] == VIR_TRISTATE_SWITCH_ON) { > > + virBufferAddLit(&buf, ",rapl=true"); > > + > > + if (def->kvm_features->rapl_helper_socket != NULL) { > > + virBufferAsprintf(&buf, ",rapl-helper-socket=%s", def->kvm_features->rapl_helper_socket); > > + } > > + } > > break; > > > > case VIR_DOMAIN_VIRT_HVF: > > Apart from that the rest looks good providing the following: > > I suppose that the 'rapl-helper-socket' is a shared (multiple qemu's use > it) resource set up beforehand by the admin. Right? The qemu-pr-helper could be run as a single instnce, or it could be run per-QEMU instance. The latter would give us better security isolation, for what is a privileged daemon. On the other hand, I wonder about the CPU overhead of having 100's of copies of the process running on a host. > If that is the case that means the lifecycle of the daemon and > permissions (including selinux) for accessing the socket are not > something that libvirt needs to deal with. > > If either of them isn't true please outline how that socket is to be > used to see how libvirt will need to approach it. > 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 :|
