Re: [Xen-devel] [PATCH 01/10] VMX: Enable EPT A/D bit support

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 02/04/15 07:32, Kai Huang wrote:
>
>>> +
>>>       table = map_domain_page(new_ept.mfn);
>>>       trunk = 1UL << ((level - 1) * EPT_TABLE_ORDER);
>>>   @@ -244,7 +247,7 @@ static int ept_split_super_page(struct
>>> p2m_domain *p2m, ept_entry_t *ept_entry,
>>>           epte->sp = (level > 1);
>>>           epte->mfn += i * trunk;
>>>           epte->snp = (iommu_enabled && iommu_snoop);
>>> -        ASSERT(!epte->rsvd1);
>>> +        /* A/D bits are inherited from superpage */
>>>           ASSERT(!epte->avail3);
>>>             ept_p2m_type_to_flags(epte, epte->sa_p2mt, epte->access);
>>> @@ -1071,6 +1074,9 @@ int ept_p2m_init(struct p2m_domain *p2m)
>>>       /* set EPT page-walk length, now it's actual walk length - 1,
>>> i.e. 3 */
>>>       ept->ept_wl = 3;
>>>   +    /* Enable EPT A/D bit if it's supported by hardware */
>>> +    ept->ept_ad = cpu_has_vmx_ept_ad_bit ? 1 : 0;
>> This will incur overhead on all EPT operations.  It should only be
>> enabled if pml is going to be in use.  (I think you need reverse patches
>> 1 and 2 in the series, and gate on pml_enable here)
> Hi Andrew,
>
> I'd like to also put patch 3 (PML feature detection) before this
> patch, as it's better to use cpu_has_vmx_pml to gate A/D bit enabling
> here. Theoretically simple "pml_enable = 1" here doesn't guarantee
> cpu_has_vmx_pml to be true, as PML may be turned off during
> vmx_init_vmcs_config.
>
> And in this case I also want to delete below code, as if PML is not
> enabled, below code will print but actually EPT A/D bits is not
> enabled in hardware.
>
>    P(cpu_has_vmx_ept_ad, "EPT A/D bit");
>

Sounds sensible.

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