>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).
It seems The whitepaper doesn't say it is not supported either. from my understanding, it should be supported. whenever a dirty flag in a leaf EPT table entry that points to the final machine frame (4KB or 2MB,..) is set, the corresponding written address will be logged. >2) a single entry will be written which must be taken to cover the >entire 2M range. I think yes, and any subsequent writes to the same 2M range address won't be updated to the log entry. >3) an individual entry is written for every access. If I understand correctly for this, only the first write access for the same 2M page (or 4K page if 4KB size is used in EPT). >Have I missed anything? > >~Andrew Bing
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
