[libvirt] Can jobs suck like qemu-pr-helper does be transfered to libvirtd?

[Zhangbo (Oscar)]

>[...]
>
>> >>This does not play well with the fact that processes as the PR helper
>> >>are always required.
>> >>
>> >>Merging them into libvirtd would make the VM stop until libvirtd is
>> >>running again. Additionally if any of the operations require persistent
>> >>kernel state as e.g. file descriptors, this would be impossible as
>> >>stopping libvirtd process would close the FDs which may be then
>> >>impossible to reopen properly e.g. due to state.
>> >
>> >Thanks! Besides these reasons above, will it weaken security if we let libvirtd
>do
>> >these jobs? For example,
>> >Such sayings, like "libvirtd would become the focus from attacking forces",
>make
>> >sense?
>>
>> If there's no security concern, then, will it be OK to add a new KVM ioctl, which
>allows
>> qemu to ask kvm module to do the high prilidged jobs?
>
>Well there actually is security concern in qemu. Libvirt attempts to run
>qemu with the least amount of privileges possible as the 'untrusted'
>guest interacts directly with qemu.
>
>That is in the end the reason 'qemu-pr-helper' exists separately.

Then, suppose we have this scenario:
1 Inside the guest,  the user binds certain irqs to certain vcpus
2 qemu helps to bind the irqs to the pcpus

Besides letting another agent daemon(similar to pr-helper) to do the binding job, can
we add a new KVM ioctl and let qemu call kvm module to do the binding job?