[...]
> >>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?