Re: [PATCH 3/3] x86/mem_sharing: make fork_reset more configurable

[Tamas K Lengyel <tamas@xxxxxxxxxxxxx>]

On Thu, Mar 24, 2022 at 11:46 AM Roger Pau Monné <roger.pau@xxxxxxxxxx> wrote:
>
> On Tue, Mar 22, 2022 at 01:41:39PM -0400, Tamas K Lengyel wrote:
> > diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
> > index 208d8dcbd9..30ce23c5a7 100644
> > --- a/xen/include/public/memory.h
> > +++ b/xen/include/public/memory.h
> > @@ -541,12 +541,14 @@ struct xen_mem_sharing_op {
> >                  uint32_t gref;     /* IN: gref to debug         */
> >              } u;
> >          } debug;
> > -        struct mem_sharing_op_fork {      /* OP_FORK */
> > +        struct mem_sharing_op_fork {      /* OP_FORK/_RESET */
> >              domid_t parent_domain;        /* IN: parent's domain id */
> >  /* These flags only makes sense for short-lived forks */
> >  #define XENMEM_FORK_WITH_IOMMU_ALLOWED (1u << 0)
> >  #define XENMEM_FORK_BLOCK_INTERRUPTS   (1u << 1)
> >  #define XENMEM_FORK_SKIP_SPECIAL_PAGES (1u << 2)
> > +#define XENMEM_FORK_RESET_STATE        (1u << 3)
> > +#define XENMEM_FORK_RESET_MEMORY       (1u << 4)
> >              uint16_t flags;               /* IN: optional settings */
> >              uint32_t pad;                 /* Must be set to 0 */
> >          } fork;
> > diff --git a/xen/include/public/vm_event.h b/xen/include/public/vm_event.h
> > index bb003d21d0..81c2ee28cc 100644
> > --- a/xen/include/public/vm_event.h
> > +++ b/xen/include/public/vm_event.h
> > @@ -127,6 +127,14 @@
> >   * Reset the vmtrace buffer (if vmtrace is enabled)
> >   */
> >  #define VM_EVENT_FLAG_RESET_VMTRACE      (1 << 13)
> > +/*
> > + * Reset the VM state (if VM is fork)
> > + */
> > +#define VM_EVENT_FLAG_RESET_FORK_STATE   (1 << 14)
> > +/*
> > + * Remove unshared entried from physmap (if VM is fork)
> > + */
> > +#define VM_EVENT_FLAG_RESET_FORK_MEMORY  (1 << 15)
>
> I'm confused about why two different interfaces are added to do this
> kind of selective resets, one to vm_event and one to xenmem_fork?
>
> I thin k the natural place for the option to live would be
> XENMEM_FORK?

Yes, that's the natural place for it. But we are adding it to both for
a reason. In our use-case the reset operation will happen after a
vm_event is received to which we already must send a reply. Setting
the flag on the vm_event reply saves us having to issue an extra memop
hypercall afterwards.

Tamas