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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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.

> 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.

~Andrew


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