Re: [Xen-devel] Buggy interaction of live migration and p2m updates

[Jürgen Groß <jgross@xxxxxxxx>]

On 11/21/2014 01:15 PM, Jan Beulich wrote:
> > > > On 21.11.14 at 12:24, <Ian.Campbell@xxxxxxxxxx> wrote:
> > On Fri, 2014-11-21 at 12:20 +0100, Juergen Gross wrote:
> > > On 11/21/2014 12:15 PM, Ian Campbell wrote:
> > > > On Fri, 2014-11-21 at 11:07 +0000, Andrew Cooper wrote:
> > > > > On 21/11/14 10:46, Ian Campbell wrote:
> > > > > > On Fri, 2014-11-21 at 10:24 +0000, Andrew Cooper wrote:
> > > > > > > On 21/11/14 09:43, Ian Campbell wrote:
> > > > > > > > I don't see any (explicit) mention of the pfn_to_mfn_frame_list_list
> > > > > > > > here, where does that fit in?
> > > > > > > It is referenced several times, although not by its exact name.
> > > > > > Hence no explicit mention.
> > > > > >
> > > > > > It's ambiguous when you refer to "higher level frames" (which I presume
> > > > > > are the reference you are referring to) because some kernels (perhaps
> > > > > > only historic ones, I've not been keeping up) keep both an N-level tree
> > > > > > of their own internally and the toolstack visible frame_list_list
> > > > > > (sometimes partially overlapping at some level). Is every reference to
> > > > > > "higher level frames" actually intended to be a reference to
> > > > > > pfn_to_mfn_frame_list_list or not?
> > > > > "higher level frames" would be the toolstack-abi-defined first and
> > > > > second level lists.  The logdirty infrastructure can be used to detect
> > > > > writes to these frames, and therefore detect structural changes to the p2m.
> > > > >
> > > > > I would like to hope that every kernel out there keeps this information
> > > > > correctly up-to-date and updates it in an appropriate order...
> > > > >
> > > > > > It seems like sometimes you are talking at times about tracking the
> > > > > > kernel's internal structure and not just pfn_to_mfn_frame_list_list and
> > > > > > I'm not sure why that would be.
> > > > > I apologise for giving this impression.  It was not intended.
> > > > Great, I just wanted to be sure we were all on the same page, since
> > > > scrobbling around in the kernel's internal data structures would clearly
> > > > be mad...
> > > >
> > > > > > I'm also not sure why
> > > > > > pfn_to_mfn_frame_list_list is apparently discounted in the linear case,
> > > > > > AFAIK the guest is still obliged to keep that up to date regardless of
> > > > > > the scheme it uses internally for accessing the p2m.
> > > > > There are two reasons for the virtual linear p2m, the primary one being
> > > > > to break the hard 512GB limit given the old 3-level table.
> > > > >
> > > > > A 64bit PV guest cannot possibly use the pfn_to_mfn_frame_list_list if
> > > > > it needs to actually exceed 512GB of RAM.  Therefore, to signal the use
> > > > > the virtual linear method, a PV guest explicitly sets
> > > > > pfn_to_mfn_frame_list_list to INVALID_MFN, and fills in the brand new
> > > > > adjacent information.
> > > > Oh, I hadn't realised this linear p2m stuff involved a guest ABI change.
> > > > Have I somehow completely missed the xen.git side of these patches? I
> > > > thought I'd only seen linux.git ones (and hence wasn't looking very
> > > > closely).
> > > V1 of the patches suggesting such a change have been posted a week ago:
> > >
> > > http://lists.xen.org/archives/html/xen-devel/2014-11/msg01276.html
> > Ah, thanks. I had indeed ignored that as "just another iteration of the
> > linux patches", oops!
> So did I, not the least because it was sent to David and Konrad
> rather than Cc-ing the hypervisor side maintainers (other than
> me).
Oops, sorry.

Will do better for V2.


Juergen


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