[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.