Re: [PATCH v2 1/1] qemu: Add support for RAPL MSRs feature
On Tue, Sep 03, 2024 at 13:29:28 +0200, Anthony Harivel wrote:
Daniel P. Berrangé, Sep 03, 2024 at 12:08:
> 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.
> > 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.
So when I was originally skimming trhough the docs I didn't properly
understand that the reason for the helper daemon is that there was a
security issue with accessing the measurement counters and thought it
was strictly for performance reasons.
If it runs on a single instance, then the socket needs to be
chmod/chown
to something like qemu / libvirt group with access only to root and
group.
Another alternative for a shared instance to be used by multiple qemu
instances is that libvirt can open the socket and pass it to qemu, which
avoids the potential issue at-least with DAC security labels as the
socket can be owned by root:root with mode 600.
I'm not sure how the selinux policy for that daemon looks though.
Running one helper instance per-QEMU instance would mean that every
instance read 1 MSR / Package every second. The socket is left open
(thanks to Daniel suggestion in QEMU review). The impact would be quite
low I guess on the housekeeping CPU.
When I designed the daemon with Paolo, the first solution was the main
idea but I'm open to any solution that leads to a better adoption of the
feature.
Libvirt can obviously manage also a per VM instance, which should be
straightforward, but not as simple as this patch. This can theoretically
also be added later, e.g. by adding a 'managed' property enabling the
libvirt-managed daemon.