Re: [v2 10/11] log-dirty: refine common code to support PML

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

On 04/17/2015 02:28 PM, Jan Beulich wrote:
>>>> On 17.04.15 at 04:46, <kai.huang@linux.intel.com> wrote:
>> On 04/16/2015 11:51 PM, Jan Beulich wrote:
>>>>>> On 15.04.15 at 09:03, <kai.huang@linux.intel.com> wrote:
>>>> @@ -190,9 +196,15 @@ static int hap_enable_log_dirty(struct domain *d, bool_t log_global)
>>>>        d->arch.paging.mode |= PG_log_dirty;
>>>>        paging_unlock(d);
>>>>    
>>>> +    /* enable hardware-assisted log-dirty if it is supported */
>>>> +    p2m_enable_hardware_log_dirty(d);
>>> I don't see that you would anywhere avoid setting up software
>>> log-dirty handling - is that on purpose? If so, is there really a
>>> win from adding PML?
>>>
>>>>        if ( log_global )
>>>>        {
>>>> -        /* set l1e entries of P2M table to be read-only. */
>>>> +        /*
>>>> +         * switch to log dirty mode, either by setting l1e entries of P2M table
>>>> +         * to be read-only, or via hardware-assisted log-dirty.
>>>> +         */
>>>>            p2m_change_entry_type_global(d, p2m_ram_rw, p2m_ram_logdirty);
>>> Or did I miss you changing the behavior of this anywhere (as the
>>> changed comment suggests)?
>> Both of your comments are done in patch 11.
> Partly - the new behavior indeed gets added there, but the misconfig
> VM exits still seem to be a necessary part of the logic, so the question
> stands: Is there really a win from adding PML? Or wait, I think now I
> recall - the benefit comes from avoiding the protection violation exits,
> not the misconfig ones. Sorry for the noise then.
Yes PML is targeted to significantly reduce number of EPT violation 
caused by write protection of guest memory, and thus reduce hypervisor 
overhead of log-dirty mechanism.

Thanks,
-Kai
>
> Jan
>