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

Re: [Xen-devel] PML (Page Modification Logging) design for Xen

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

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?


Xen-devel mailing list



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