Re: [Xen-devel] [PATCH v9 3/5] xen/mem_sharing: VM forking

[Tamas K Lengyel <tamas@xxxxxxxxxxxxx>]

> > Note also that during a restore the guest is aware of such process,
> > and will know that it needs to re-register some stuff, but that's not
> > the case when forking, since the guest is not aware you need to make
> > sure everything is in place. There are also the grant table pages,
> > which I think should also be handled somehow (or we need to at least
> > note this isn't handled and will need fixing).
>
> True, the fork is not aware that something happened (and we want to
> keep it that way). But right now everything seems to "just work" as
> far as a standard VM is used. There must be a million cornercases left
> that I haven't covered for sure.
>

I've implemented forking for the vcpu_info pages and while I was
testing I noticed that a Linux VM behaves differently during forking
compared to a Windows VM. Forking a Windows VM at runtime works all
fine, VNC screen is responsive, can log in and in every way the fork
behaves like a regular domain. Forking the Linux VM however at runtime
results in a frozen VNC screen. The VM runs fine otherwise, I use it
in my fuzz tests and tracing it via VMI shows that both the kernel and
userspace programs continue to execute in the fork normally. So there
must be some "glue" the Linux guest needs to wire things up with the
toolstack that I'm missing. When I first save the Linux VM and restore
it with "xl restore -p" and then create forks the VNC console becomes
responsive just as with the Windows VM.

At the moment it's not entirely clear to me what I'm missing that the
Linux guest needs so I'm inclined to declare this a known limitation
and move on since it's not critical for our use-case.

Tamas

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel