Re: PML (Page Modification Logging) design for Xen

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

On 12/02/15 06:54, Tian, Kevin wrote:
>
>>> which presumably
>>> means that the PML buffer flush needs to be aware of which gfns are
>>> mapped by superpages to be able to correctly set a block of bits in the
>>> logdirty bitmap.
>>>
>> Unfortunately PML itself can't tell us if the logged GPA comes from
>> superpage or not, but even in PML we still need to split superpages to
>> 4K page, just like traditional write protection approach does. I think
>> this is because live migration should be based on 4K page granularity.
>> Marking all 512 bits of a 2M page to be dirty by a single write doesn't
>> make sense in both write protection and PML cases.
>>
> agree. extending one write to superpage enlarges dirty set unnecessary.
> since spec doesn't say superpage logging is not supported, I'd think a
> 4k-aligned entry being logged if within superpage.

The spec states that an gfn is appended to the log strictly on the
transition of the D bit from 0 to 1.

In the case of a 2M superpage, there is a single D bit for the entire 2M
range.


The plausible (working) scenarios I can see are:

1) superpages are not supported (not indicated by the whitepaper).
2) a single entry will be written which must be taken to cover the
entire 2M range.
3) an individual entry is written for every access.

Have I missed anything?

~Andrew