[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 12:01 PM, Jan Beulich wrote:
>>>> On 05.10.18 at 10:41, <rcojocaru@xxxxxxxxxxxxxxx> wrote:
>> 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?
> 
> Afaic - I'd prefer the functions to remain as they are, with _new_
> ept_{en,dis}able_hardware_log_dirty() introduced, to be put in
> the hook pointers. The new functions would then call the existing
> ones for all P2Ms (with the host p2m lock acquired). The question
> then is what to do with the calls to the domain-scope
> vmx_domain_{en,dis}able_pml(); looking at its implementation I
> think it could simply stay where it is. The boolean
> vmx_domain_pml_enabled() would need to eventually change to
> an enable count, but that's nothing you need to be concerned
> about for your purposes.
> 
> But again - please check what maintainers want before going
> this route.

I see, in which case George please let me know if you're okay with Jan's
suggestion when you get a chance to read the thread.


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®.