[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [v2 10/11] log-dirty: refine common code to support PML
On 04/17/2015 02:28 PM, Jan Beulich wrote:
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.
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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
