On Thu, Sep 05, 2024 at 13:01:53 +0200, Anthony Harivel wrote: > > Hi, > > Anthony Harivel, Sep 03, 2024 at 14:41: > > Daniel P. Berrangé, Sep 03, 2024 at 14:24: > > > On Tue, Sep 03, 2024 at 02:16:58PM +0200, Peter Krempa wrote: > > > > 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:
[...] > If I may resume the conversation: > > 1) The helper daemon is primarily needed for security reasons to prevent > potential leaks of confidential information through RAPL. > > 2) There are two main ways to handle the helper daemon: > > Single instance for all QEMU processes: > This requires adjusting socket permissions (chmod/chown) to control > access securely. > > One instance per QEMU process: This offers better isolation but > might increase CPU overhead slightly if the number of instances > running get high. > > 3) Libvirt can manage both approaches, but no existing SELinux policy > covers this yet, so we’ll need to consider that. The question is also which of the approaches will actually be used. Implementing both is possible, it's just whether the managed approach will be used in the end. > 4) qemu-pr-helper is very similar to the qemu-vmsr-helper in terms of > architecture and in terms of privileged needs. It can be single > shared instance or per-vm instance. > > > I cannot find the original patch that has added qemu-pr-helper into > libvirt. The latest commit in src/qemu/qemu_process is 7eead248c65f > and it doesn't look right IMHO. > > If you have a reference to the original patch, I can use it as a guide > to implement this helper in the same way, if you believe that is the > best solution. The qemu-pr-helper was introduced in libvirt in commits b0cd8045f012af78e863cd19f74e9db6c1b5dfdd and few prior ones. Note that it was a very long time ago so the code will likely no longer be state of the art. Also note that for 'qemu-pr-helper' it's much more complicated as it needs to be handled also for hotplug of disks when a new instance might need to be started. Here you'll only ever have one instance, that shares the lifetime with the VM, which makes few things much simpler (much less wiring up weird corner cases). In case we do in fact want a libvirt-managed version of this the question is also how to handle potential cases e.g. when the libvirt-managed daemon gets killed/crashes. The PR manager daemon has some form of event handlign which will restart and reconnect it. Is that needed here as well?
