Re: [Xen-devel] [PATCH v5][XSA-97] x86/paging: make log-dirty operations preemptible

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 15/09/2014 15:20, Jan Beulich wrote:
> > > > On 15.09.14 at 15:56, <andrew.cooper3@xxxxxxxxxx> wrote:
> > On 15/09/2014 13:54, Jan Beulich wrote:
> > > > > > On 15.09.14 at 09:50, <andrew.cooper3@xxxxxxxxxx> wrote:
> > > > It is indeed migration v2, which is necessary in XenServer given our
> > > > recent switch from 32bit dom0 to 64bit.  The counts are only used for
> > > > logging, and debugging purposes; all movement of pages is based off the
> > > > bits in the bitmap alone.  In particular, the dirty count is used as a
> > > > basis of the statistics for the present iteration of migration.  While
> > > > getting it wrong is not the end of the world, it would certainly be
> > > > preferable for the count to be accurate.
> > > >
> > > > As for the memory corruption, XenRT usually tests pairs of VMs at a time
> > > > (32 and 64bit variants) and all operations as back-to-back as possible.
> > > > Therefore, it is highly likely that a continued operation on one domain
> > > > intersects with other paging operations on another.
> > > But there's nothing I can see where domains would have a way
> > > of getting mismatched. It is in particular this one
> > >
> > > (XEN) [ 7832.953068] mm.c:827:d0v0 pg_owner 100 l1e_owner 100, but
> > real_pg_owner 99
> > > which puzzles me: Assuming Dom99 was the original one, how
> > > would Dom100 get hold of any of Dom99's pages (IOW why would
> > > Dom0 map one of Dom99's pages into Dom100)? The patch doesn't
> > > alter any of the page refcounting after all. Nor does your v2
> > > migration series I would think.
> > In this case, dom99 was migrating to dom100.  The failure was part of
> > verifying dom100v0's cr3 at the point of loading vcpu state, so Xen was
> > in the process of pinning pagetables.
> >
> > There were no errors on pagetable normalisation, so dom99's PTEs were
> > all correct, and there were no errors restoring any of dom100's memory,
> > so Xen fully allocated frames for dom100's memory during
> > populate_phymap() hypercalls.
> >
> > During pagetable normalisation, dom99's pfns in the stream are converted
> > to dom100's mfns as per the newly created p2m from the
> > populate_physmap() allocations.  Then during dom100's cr3 validation, it
> > finds a dom99 PTE and complains.
> >
> > Therefore, a frame Xen handed back to the toolstack as part of
> > allocating dom100's memory still belonged to dom99.
> Or on the saving side some page table(s) didn't get normalized at
> all (in which case there necessarily also were no errors detected
> with that). Not being marked as page table(s) would then also lead
> to not getting converted back to machine representation on restore,
> resulting in a reference to a page belonging to the old domain.
>
> But together with the memory corruption you mentioned seen in
> HVM guests all of the above may just be secondary effects.
Yes - that is my suspicion as well, although I was hoping that the 
failures would give some hints as to the root cause.
~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel