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.hu...@linux.intel.com wrote:
On 04/16/2015 11:51 PM, Jan Beulich wrote:
On 15.04.15 at 09:03, kai.hu...@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
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [v2 10/11] log-dirty: refine common code to support PML
On 17.04.15 at 04:46, kai.hu...@linux.intel.com wrote:
On 04/16/2015 11:51 PM, Jan Beulich wrote:
On 15.04.15 at 09:03, kai.hu...@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.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [v2 10/11] log-dirty: refine common code to support PML
On 15.04.15 at 09:03, kai.hu...@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)?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [v2 10/11] log-dirty: refine common code to support PML
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Thursday, April 16, 2015 11:52 PM
On 15.04.15 at 09:03, kai.hu...@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)?
just found behavior is changed in [11/11]. :-)
Thanks
Kevin
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [v2 10/11] log-dirty: refine common code to support PML
On 04/16/2015 11:51 PM, Jan Beulich wrote:
On 15.04.15 at 09:03, kai.hu...@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.
And I think even without patch 11, there's no harm with this patch as
p2m_enable_hardware_log_dirty will essentially do nothing and write
protection will be used for log-dirty :)
Thanks,
-Kai
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [v2 10/11] log-dirty: refine common code to support PML
On 04/17/2015 07:07 AM, Tian, Kevin wrote:
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Thursday, April 16, 2015 11:52 PM
On 15.04.15 at 09:03, kai.hu...@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)?
just found behavior is changed in [11/11]. :-)
Yes.
Thanks,
-Kai
Thanks
Kevin
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
