Re: [Xen-devel] [PATCH 2/2] xen/mm: Introduce PGC_state_uninitialised

[Paul Durrant <xadimgnik@xxxxxxxxx>]

> -----Original Message-----
> > > diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
> > > index 62507ca651..5f0581c072 100644
> > > --- a/xen/arch/x86/mm.c
> > > +++ b/xen/arch/x86/mm.c
> > > @@ -491,7 +491,8 @@ void share_xen_page_with_guest(struct page_info 
> > > *page, struct domain *d,
> > >
> > >      page_set_owner(page, d);
> > >      smp_wmb(); /* install valid domain ptr before updating refcnt. */
> > > -    ASSERT((page->count_info & ~PGC_xen_heap) == 0);
> > > +    ASSERT((page->count_info & ~PGC_xen_heap) == PGC_state_inuse ||
> > > +           (page->count_info & ~PGC_xen_heap) == 
> > > PGC_state_uninitialised);
> >
> > Could the page state perhaps be bumped to inuse in this case? It
> > seems odd to leave state uninitialized yet succeed in sharing with a
> > guest.
> 
> No, that doesn't really work.
> 
> You can't just *declare* that the page was properly initialised,
> because it isn't true. There's a pathological case where the zone
> hasn't been initialised at all, because *all* the pages in that zone
> got handed out by the boot allocator or used for initrd etc.
> 
> The first pages 'freed' in that zone end up being used (in
> init_heap_pages) to create the zone structures.
> 
> Likewise, it could include a page which init_heap_pages() doesn't
> actually *put* into the buddy allocator, to work around the cross-zone
> merge problem. It's fine to use that page and share it with a guest,
> but it can't ever be freed into the buddy allocator.
> 

Ok, so deferring the call to free_heap_pages() (and consequently 
init_heap_pages()) is safe to defer until the guest is torn down? (Or is this 
only safe if the page is being assigned to the initial domain?)

  Paul


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