Re: [Xen-devel] 4.11.0 RC1 panic

[Manuel Bouyer <bouyer@xxxxxxxxxxxxxxx>]

On Sun, Jun 10, 2018 at 09:38:17AM -0600, Jan Beulich wrote:
> >>> Manuel Bouyer <bouyer@xxxxxxxxxxxxxxx> 06/10/18 1:30 PM >>>
> >When a new set of page tables is needed (this is pmap_create()), a pdp is
> >requested from a cache.  If the cache is empty, pages are allocated in
> >pmap_pdp_ctor(), which is going to also pin the L2 pages.
> >When the page table is not needed any more (this is pmap_destroy()),
> >the pdp is returned to the cache.  L2 pages remains pinned, with pointers to
> >the kernel L1 pages.  If memory needs to be reclaimed from the cache,
> >or is an explicit call to pool_cache_destruct_object() is done, 
> >the L2 pages are unpinned, but they are not explicitely zeroed out before
> >(can this be a problem ?).
> 
> I don't think so, no. Whatever is still in there is going to have respective
> refcounts dropped while unvalidating the L2.
> 
> But I conclude that if there is an L2 unpin, that L2 is not expected to be in 
> use
> (as an L2) anywhere anymore, i.e. the only type reference is supposed to be
> the one associated with the pinned status.

Yes, I think so.

> Nor is it expected for L2s to ever
> get freed by other means than unpinning (i.e. by them being taken off an L3).

Yes, that should be true.

One thing I forgot to mention: NetBSD allocates one L3 per CPU, for the life
of the system (L3 are never freed). Context switching is done by updating the
entries in these L3s.


> If that's the case, maybe there is a way to place some more (NetBSD-specific)
> assertions in a few places ...
> 
> 
> What about L2 tables to be used in slot 3 of an L3 table? Aiui Xen won't allow
> them to be pinned, hence I'd expect there to be some special casing in your
> code. Considering no similar issues have been observed with 64-bit guests,
> this one special case looks to me to be the prime suspect for something going
> wrong (in Xen).

AFAIK this L2 is allocated at boot, and should never be freed. It's
shared by all CPUs.

There is one special L2 case: it's pinned as L2 but used as L1 in the "kernel"
L2 (the one in slot 3 of the L3 tables). This is for recursive mappings
of the kernel map. This one will be allocated/freed (and so pinned/unpinned)
for each context.

-- 
Manuel Bouyer <bouyer@xxxxxxxxxxxxxxx>
     NetBSD: 26 ans d'experience feront toujours la difference
--

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