Re: [Xen-devel] [PATCH 1/2] x86/ept: defer enabling of EPT A/D bit until PML get enabled.

2015-10-20 Thread Tian, Kevin
> From: Kai Huang [mailto:kai.hu...@linux.intel.com] > Sent: Tuesday, October 20, 2015 10:35 AM > > Existing PML implementation turns on EPT A/D bit unconditionally if PML is > supported by hardware. This works but enabling of EPT A/D bit can be deferred > until PML get enabled. There's no point i

Re: [Xen-devel] [PATCH 1/2] x86/ept: defer enabling of EPT A/D bit until PML get enabled.

2015-10-20 Thread Andrew Cooper
On 20/10/15 03:34, Kai Huang wrote: > Existing PML implementation turns on EPT A/D bit unconditionally if PML is > supported by hardware. This works but enabling of EPT A/D bit can be deferred > until PML get enabled. There's no point in enabling the extra feature for > every > domain when we're n

Re: [Xen-devel] [PATCH 1/2] x86/ept: defer enabling of EPT A/D bit until PML get enabled.

2015-10-20 Thread Jan Beulich
>>> On 20.10.15 at 04:34, wrote: > Existing PML implementation turns on EPT A/D bit unconditionally if PML is > supported by hardware. This works but enabling of EPT A/D bit can be > deferred > until PML get enabled. There's no point in enabling the extra feature for > every > domain when we're

[Xen-devel] [PATCH 1/2] x86/ept: defer enabling of EPT A/D bit until PML get enabled.

2015-10-19 Thread Kai Huang
Existing PML implementation turns on EPT A/D bit unconditionally if PML is supported by hardware. This works but enabling of EPT A/D bit can be deferred until PML get enabled. There's no point in enabling the extra feature for every domain when we're not meaning to use it (yet). Also added ASSERT