Re: PML (Page Modification Logging) design for Xen

[Kai Huang <kai.huang@linux.intel.com>]

On 02/12/2015 02:54 PM, Tian, Kevin wrote:
>> From: Kai Huang [mailto:kai.huang@linux.intel.com]
>> Sent: Thursday, February 12, 2015 10:39 AM
>>>> PML needs to be enabled (allocate PML buffer, initialize PML index,
>>>> PML base address, turn PML on VMCS, etc) for all vcpus of the domain,
>>>> as PML buffer and PML index are per-vcpu, but EPT table may be shared
>>>> by vcpus. Enabling PML on partial vcpus of the domain won't work. Also
>>>> PML will only be enabled for the domain when it is switched to dirty
>>>> logging mode, and it will be disabled when domain is switched back to
>>>> normal mode. As looks vcpu number won't be changed dynamically during
>>>> guest is running (correct me if I am wrong here), so we don't have to
>>>> consider enabling PML for new created vcpu when guest is in dirty
>>>> logging mode.
>>> There are exactly d->max_vcpus worth of struct vcpus (and therefore
>>> VMCSes) for a domain after creation, and will exist for the lifetime of
>>> the domain.  There is no dynamic adjustment of numbers of vcpus during
>>> runtime.
>> Good to know.
> could we at least detect and warn vcpu changes when PML is enabled?
> dirty logging happens out of guest's knowledge and there could be the
> case where user right online/offline a vcpu within that window.
Why is the warning necessary? There's no harm leaving PML enabled when 
vcpu becomes offline.

Also we will not disable PML for that vcpu when it becomes offline, in 
which case we don't need to re-enable PML, which can fail, when vcpu 
becomes online again. It simplifies the logic.

Thanks,
-Kai
>
>>> 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.
>
> Thanks
> Kevin
>