[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH V3] x86/altp2m: propagate ept.ad changes to all active altp2ms



On 10/5/18 11:17 AM, Jan Beulich wrote:
>>>> On 04.10.18 at 18:40, <rcojocaru@xxxxxxxxxxxxxxx> wrote:
>> On 10/4/18 7:04 PM, Jan Beulich wrote:
>>>>>> On 02.10.18 at 17:17, <rcojocaru@xxxxxxxxxxxxxxx> wrote:
>>>>  static void ept_enable_pml(struct p2m_domain *p2m)
>>>>  {
>>>> +    struct domain *d = p2m->domain;
>>>> +    struct p2m_domain *hostp2m = p2m_get_hostp2m(d);
>>>> +
>>>> +    p2m_lock(hostp2m);
>>>> +
>>>>      /* Domain must have been paused */
>>>> -    ASSERT(atomic_read(&p2m->domain->pause_count));
>>>> +    ASSERT(atomic_read(&d->pause_count));
>>>>  
>>>>      /*
>>>>       * No need to return whether vmx_domain_enable_pml has succeeded, as
>>>>       * ept_p2m_type_to_flags will do the check, and write protection will 
>>>> be
>>>>       * used if PML is not enabled.
>>>>       */
>>>> -    if ( vmx_domain_enable_pml(p2m->domain) )
>>>> +    if ( vmx_domain_enable_pml(d) )
>>>>          return;
>>>>  
>>>>      /* Enable EPT A/D bit for PML */
>>>> -    p2m->ept.ad = 1;
>>>> -    vmx_domain_update_eptp(p2m->domain);
>>>> +    ept_set_ad_sync(hostp2m, true);
>>>> +
>>>> +    vmx_domain_update_eptp(d);
>>>> +
>>>> +    p2m_unlock(hostp2m);
>>>>  }
>>>>  
>>>>  static void ept_disable_pml(struct p2m_domain *p2m)
>>>>  {
>>>> +    struct domain *d = p2m->domain;
>>>> +    struct p2m_domain *hostp2m = p2m_get_hostp2m(d);
>>>> +
>>>> +    p2m_lock(hostp2m);
>>>> +
>>>>      /* Domain must have been paused */
>>>> -    ASSERT(atomic_read(&p2m->domain->pause_count));
>>>> +    ASSERT(atomic_read(&d->pause_count));
>>>>  
>>>> -    vmx_domain_disable_pml(p2m->domain);
>>>> +    vmx_domain_disable_pml(d);
>>>>  
>>>>      /* Disable EPT A/D bit */
>>>> -    p2m->ept.ad = 0;
>>>> -    vmx_domain_update_eptp(p2m->domain);
>>>> +    ept_set_ad_sync(hostp2m, false);
>>>> +
>>>> +    vmx_domain_update_eptp(d);
>>>> +
>>>> +    p2m_unlock(hostp2m);
>>>>  }
>>>
>>> While in certain cases I would appreciate such transformations,
>>> I'm afraid the switch from p2m->domain to d in these two
>>> functions is hiding the meat of the change pretty well. In
>>> particular it is only now that I notice that you go from passed in
>>> p2m to domain to hostp2m. This makes me assume some altp2m
>>> could come in here too. Is it really intended for a change to
>>> an altp2m to be propagate to the hostp2m (and all other
>>> altp2m-s)? I can see why altp2m-s want to stay in sync (in
>>> certain regards) with the hostp2m, but for a sync the other
>>> way around there need to be deeper reasons.
>>>
>>> I admit that part of the problem here might be that the whole
>>> function hierarchy you change is tied to log-dirty enabling/
>>> disabling, but I'm not convinced PML as well as A/D enabled
>>> status has to always match global(?) log-dirty enabled status.
>>>
>>> But I'm not the maintainer of this code, so please don't
>>> interpret my response as a strict request for change.
>>
>> As far as I've understood from George, they do all need to be kept in
>> sync. And I see no reason why an altp2m couldn't be passed in there as
>> well - are you referring to the fact that p2m->domain is not right in
>> that case? I should probably add p2m->domain = hostp2m->domain; in
>> p2m_init_altp2m_ept() in this patch, I think that slipped when I've
>> split the patches.
> 
> No, I don't think the domain pointer can conflict. Instead I think
> there could be reasons why one view may want to have A/D
> and/or PML activated without this being wanted/needed on all
> others, let alone the host one. But I've meanwhile realized that
> this may also merely be a function naming issue:
> ept_{en,dis}able_pml are not overly helpful names for something
> to be put in directly as {en,dis}able_hardware_log_dirty hooks.
> By their names, the functions should act on just the specified
> P2M imo. The hook handlers, otoh, would validly sync the setting
> to all P2Ms, as log-dirty mode is a domain-wide setting.

Would sending out V4 with ept_{en,dis}able_pml() renamed to
ept_{en,dis}able_hardware_log_dirty() be a reasonable solution to the
problem?


Thanks,
Razvan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.