[libvirt] [PATCH 4/9] util: cgroups do not implicitly add task to new machine cgroup

[Daniel P. Berrange]

On Fri, Feb 26, 2016 at 02:17:35PM +0100, Henning Schild wrote:
> On Fri, 26 Feb 2016 13:00:04 +0000
> "Daniel P. Berrange" <berrange at redhat.com> wrote:
> 
> > On Fri, Feb 26, 2016 at 01:43:05PM +0100, Henning Schild wrote:
> > IIUC, the original problem you wanted to address was that vCPU pids
> > could run the wrong CPU for a short time. ie The original code did
> > 
> >   1. Libvirtd forks child pid
> >      ... this pid runs on whatever pCPUs that libvirt is permitted to
> > use... 2. Libvirtd creates root cgroup for VM
> >      ... this pid runs on whatever pCPUs the root cgroup inherited...
> >   3. Child pid execs QEMU
> >      ... QEMU pid runs on whatever pCPUs the root cgroup inherited...
> >   4. QEMU creates vCPU pids
> >      ... vCPU pids run on whatever pCPUs the root cgroup inherited...
> >   4. Libvirtd moves emulator PIDs and vCPU PIDs
> >      ... emulator PIDs are running on assigned pCPUs for emulator...
> >      ... vCPU PIDs are running on assigned pCPUs for vCPUs....
> > 
> > With the important change in patch 5 this now looks like
> > 
> >   1. Libvirtd forks child pid
> >      ... this pid runs on whatever pCPUs that libvirt is permitted to
> > use... 2. Libvirtd creates root cgroup for VM
> 
> >      ... this pid runs on whatever pCPUs the root cgroup inherited...
> 
> I am trying to come up with a solution that eliminates the above line
> from the whole bringup. I.e never allow a pid belonging to the VM
> outside the pinnings of libvirtd and the VM configuration.

That's imposible because you can't stop systemd placing the pid leader

> But until step 4 it should probably be
> "... this pid *just sits* on whatever pCPUs the root cgroup
> inherited..."
> If we are sure that it does not "run" before 4. patch 5 does the trick
> already

Yes the pid *runs* - it has to run in order to do the setup tasks
before exec'ing QEMU. Indeed even invoking 'execve()' syscall
requires that it run.

> >   3. Libvirtd moves pid into emulator group
> >      ... this pid runs on assigned pCPUs for emulator...
> >   4. Child pid execs QEMU
> >      ... QEMU pid runs on assigned pCPUs for emulator...
> >   5. QEMU creates vCPU pids
> >      ... vCPU pids are running on assigned pCPUS for emulator...
> >   6. Libvirtd moves vCPU PIDs
> >      ... emulator PIDs are running on assigned pCPUs for emulator...
> >      ... vCPU PIDs are running on assigned pCPUs for vCPUs....
> > 
> > Which is good, because vCPU pids don't ever run on un-restricted
> > pCPUs.
> > 
> > 
> > Your patch 4 here is attempting to change step 2 only so that it
> > looks like
> > 
> > 
> >   1. Libvirtd forks child pid
> >      ... this pid runs on whatever pCPUs that libvirt is permitted to
> > use... 2. Libvirtd creates root cgroup for VM
> >      ... this pid runs on whatever pCPUs that libvirt is permitted to
> > use... or depending on what controller system added
> >      ... this pid runs on whatever pCPUs the root cgroup inherited...
> >   3. Libvirtd adds pid into emulator group
> >      ... this pid runs on assigned pCPUs for emulator...
> >   4. Child pid execs QEMU
> >      ... QEMU pid runs on assigned pCPUs for emulator...
> >   5. QEMU creates vCPU pids
> >      ... vCPU pids are running on assigned pCPUS for emulator...
> >   6. Libvirtd moves vCPU PIDs
> >      ... emulator PIDs are running on assigned pCPUs for emulator...
> >      ... vCPU PIDs are running on assigned pCPUs for vCPUs....
> > 
> > At the time we exec QEMU in step 4 the situation is exactly the same
> > as before. The vCPU pids are still created in the right place
> > straight away.
> > 
> > So this patch 4 doesn't achieve anything useful
> > 
> > Regards,
> > Daniel
> 

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|