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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 17.04.15 at 04:46, <kai.huang@xxxxxxxxxxxxxxx> wrote:
> On 04/16/2015 11:51 PM, Jan Beulich wrote:
>>>>> On 15.04.15 at 09:03, <kai.huang@xxxxxxxxxxxxxxx> 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.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel