Ping²: [PATCH v2] x86/PV: make post-migration page state consistent

[Jan Beulich <jbeulich@xxxxxxxx>]

On 23.11.2020 13:50, Jan Beulich wrote:
> On 23.11.2020 13:26, Andrew Cooper wrote:
>> On 20/11/2020 12:48, Jan Beulich wrote:
>>> On 04.11.2020 08:56, Jan Beulich wrote:
>>>> When a page table page gets de-validated, its type reference count drops
>>>> to zero (and PGT_validated gets cleared), but its type remains intact.
>>>> XEN_DOMCTL_getpageframeinfo3, therefore, so far reported prior usage for
>>>> such pages. An intermediate write to such a page via e.g.
>>>> MMU_NORMAL_PT_UPDATE, however, would transition the page's type to
>>>> PGT_writable_page, thus altering what XEN_DOMCTL_getpageframeinfo3 would
>>>> return. In libxc the decision which pages to normalize / localize
>>>> depends solely on the type returned from the domctl. As a result without
>>>> further precautions the guest won't be able to tell whether such a page
>>>> has had its (apparent) PTE entries transitioned to the new MFNs.
>>>>
>>>> Add a check of PGT_validated, thus consistently avoiding normalization /
>>>> localization in the tool stack.
>>>>
>>>> Also use XEN_DOMCTL_PFINFO_NOTAB in the variable's initializer instead
>>>> open coding it.
>>>>
>>>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>>>> ---
>>>> v2: Don't change type's type.
>>> Ping?
>>
>> Ping what?  There is still nothing addressing my concerns from v1.
> 
> I did reply to your concerns on Sep 11th, and then replied to this
> reply of mine another time on Sep 28th. Neither of these got any
> response from you, hence I had to conclude - after two further
> pings on v1 - that they were satisfactory to you. Now you say they
> weren't, but without saying in which way, so I still wouldn't know
> what to change in the description.
> 
> On the code change itself you did say "... so this is probably a
> good change", so I was further understanding that your concern is
> merely with the description. Maybe I misunderstood this aspect,
> too?
> 
>> To re-iterate - this is a very subtle change, in a very complicated
>> piece of migration.  As the problems described do not manifest in
>> practice, it is vital to understand why.
> 
> Until now it has been my understanding that they just don't happen
> to manifest, because guests know to behave themselves (read: pin,
> first and foremost, all their page tables, which means we wouldn't
> in practice run into ones with an in-flight state change).

Another example where I think I have waited long enough for a reply.
Roger has acked the change, so unless I hear otherwise by then I'm
intending to commit this, too, once the tree is fully open again.

Jan