[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v2 3/3] x86/mem_sharing: make fork_reset more configurable
On 29.03.2022 16:03, Tamas K Lengyel wrote: > --- a/xen/arch/x86/include/asm/mem_sharing.h > +++ b/xen/arch/x86/include/asm/mem_sharing.h > @@ -85,6 +85,9 @@ static inline bool mem_sharing_is_fork(const struct domain > *d) > int mem_sharing_fork_page(struct domain *d, gfn_t gfn, > bool unsharing); > > +int mem_sharing_fork_reset(struct domain *d, bool reset_state, > + bool reset_memory); Please avoid passing multiple booleans, even more so when you already derive them from a single "flags" value. This would likely be easiest if you re-used the VM_EVENT_FLAG_RESET_FORK_* values also for XENMEM_FORK_RESET_*, with suitable BUILD_BUG_ON() put in place to prove they're the same. > --- a/xen/arch/x86/mm/mem_sharing.c > +++ b/xen/arch/x86/mm/mem_sharing.c > @@ -1890,15 +1890,24 @@ static int fork(struct domain *cd, struct domain *d, > uint16_t flags) > * footprints the hypercall continuation should be implemented (or if this > * feature needs to be become "stable"). > */ > -static int mem_sharing_fork_reset(struct domain *d) > +int mem_sharing_fork_reset(struct domain *d, bool reset_state, > + bool reset_memory) > { > - int rc; > + int rc = 0; > struct domain *pd = d->parent; > struct p2m_domain *p2m = p2m_get_hostp2m(d); > struct page_info *page, *tmp; > > + ASSERT(reset_state || reset_memory); > + > + if ( !d->arch.hvm.mem_sharing.fork_complete ) > + return -ENOSYS; Either EOPNOTSUPP (in case you think this operation could make sense to implement for incomplete forks) or e.g. EINVAL, but please not ENOSYS. > @@ -394,6 +399,16 @@ static int vm_event_resume(struct domain *d, struct > vm_event_domain *ved) > if ( rsp.reason == VM_EVENT_REASON_MEM_PAGING ) > p2m_mem_paging_resume(d, &rsp); > #endif > +#ifdef CONFIG_MEM_SHARING > + if ( mem_sharing_is_fork(d) ) > + { > + bool reset_state = rsp.flags & > VM_EVENT_FLAG_RESET_FORK_STATE; > + bool reset_mem = rsp.flags & VM_EVENT_FLAG_RESET_FORK_MEMORY; > + > + if ( reset_state || reset_mem ) > + ASSERT(!mem_sharing_fork_reset(d, reset_state, > reset_mem)); > + } > +#endif Should the two flags be rejected in the "else" case, rather than being silently ignored? > --- 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 */ I consider the notation in the comment misleading - I would read it to mean OP_FORK and OP_RESET, supported by the earlier OP_SHARE/ADD_PHYSMAP. Commonly we write OP_FORK{,_RESET} in such cases. Jan
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |