Re: [PATCH] tools/mfn-dump: Fixes to 'dump-p2m'

[Andrew Cooper <andrew.cooper3@citrix.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1680 bytes --]

On 29/04/14 16:25, Dario Faggioli wrote:
> On gio, 2014-04-24 at 22:06 +0100, Andrew Cooper wrote:
>> * Don't walk off the end of p2m_table under the mistaken impression
that it
>>   contains toolstack unsigned longs.  Despite its array type it
contains guest
>>   unsigned longs so unconditionally needs casting to the guest width
to use
>>   correctly.  Furthermore, a 64bit toolstack must be extra careful
when it
>>   finds a 32bit guest's INVALID_MFN.
>>
>> * Drop 'mapped' and 'pinned' descriptions.  This are both bogus,
including all
>>   uses of the is_mapped() macro.
>>
> Just a question, what do you mean by 'bogus' here? About pinned, I think
> I see it, and I like the way you put it in the patch. About 'mapped' and
> is_mapped()? Do you mean to say it's not useful information here?
>
> Again, just curious.

The top bit of the type has nothing to do with mappings, or certainly
nothing that I am aware of, having successfully rewritten PV migration
from scratch.

The guest can still have mappings to its pinned pagetables, which would
have the top bit of the type set.

In xc_domain_save.c, this macro is used 4 times.  3 are used on mfns and
1 is used on a type (for a bit of debugging code which appears dead
anyway).  I expect noone has every tried migrating a PV domain whose
pages are located in mfns with the 44th bit set.

So by bogus, I mean the macro itself, and all uses of it.

My best guess is that is some vestigial code left over from a previous
way of doing things, although I didn't encounter anything related to
this in code archaeology I performed when trying to work out why the
legacy migration did certain things the way they did.

~Andrew


[-- Attachment #1.2: Type: text/html, Size: 2314 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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