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

[Tamas K Lengyel <tamas@xxxxxxxxxxxxx>]

On Tue, Feb 25, 2020 at 3:05 AM Roger Pau Monné <roger.pau@xxxxxxxxxx> wrote:
>
> On Fri, Feb 21, 2020 at 10:49:21AM -0800, Tamas K Lengyel wrote:
> > VM forking is the process of creating a domain with an empty memory space 
> > and a
> > parent domain specified from which to populate the memory when necessary. 
> > For
> > the new domain to be functional the VM state is copied over as part of the 
> > fork
> > operation (HVM params, hap allocation, etc).
>
> I've just realized that I'm not sure how are special pages handled,
> what happens to the xenstore, console, shared info pages, or the
> vcpu info pages if the parent has those registered?

The fork starts out with an empty p2m so these pages are not present.
In case the guest itself tries to access these pages, or a foreign
mapping is set up for them, then that will trigger fork_page from the
parent. I see that in the VM restore path clears the pages for
HVM_PARAM_CONSOLE_PFN, HVM_PARAM_STORE_PFN, HVM_PARAM_IOREQ_PFN and
HVM_PARAM_BUFIOREQ_PFN but doesn't really explain why that would be
required. I can certainly add the same special handling for these HVM
params when they get copied during the fork hypercall.

As for the vcpu info page, I'm not sure where that gets allocated and
mapped normally. I don't see any special handling for that in the
save/restore paths. We use the standard createdomain hypercall to
setup the VM that will be used for the fork, then use vcpu_create to
bring up the vCPUs and just load them with the hvm context, pretty
much the same way the restore path would.

> Also, what happens to pages that are being used for DMA with emulated
> devices? Will QEMU foreign mappings also trigger the populate on
> demand routine, so that external emulators can access those?

Foreign mappings do trigger the fork_page routine, yes. Same for
setting mem_access permissions.

Tamas

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