Re: [Xen-devel] [PATCH V5 2/3] x86/mm: allocate logdirty_ranges for altp2ms

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 14.11.18 at 15:05, <rcojocaru@xxxxxxxxxxxxxxx> wrote:
> On 11/14/18 4:00 PM, Jan Beulich wrote:
>>>>> On 14.11.18 at 13:50, <rcojocaru@xxxxxxxxxxxxxxx> wrote:
>>> On 11/14/18 1:58 PM, George Dunlap wrote:
>>>> On 11/13/18 6:43 PM, Razvan Cojocaru wrote:
>>>>> On 11/13/18 7:57 PM, George Dunlap wrote:
>>>>>> On 11/11/18 2:07 PM, Razvan Cojocaru wrote:
>>>>>>> @@ -2341,6 +2380,7 @@ int p2m_destroy_altp2m_by_id(struct domain *d, 
>>>>>>> unsigned int idx)
>>>>>>>          {
>>>>>>>              p2m_flush_table(d->arch.altp2m_p2m[idx]);
>>>>>>>              /* Uninit and reinit ept to force TLB shootdown */
>>>>>>> +            p2m_free_logdirty(d->arch.altp2m_p2m[idx]);
>>>>>>>              ept_p2m_uninit(d->arch.altp2m_p2m[idx]);
>>>>>>>              ept_p2m_init(d->arch.altp2m_p2m[idx]);
>>>>>>>              d->arch.altp2m_eptp[idx] = mfn_x(INVALID_MFN);
>>>>>>
>>>>>> (In case I forget: Also, this is called without holding the appropriate
>>>>>> p2m lock. )
>>>>>
>>>>> Could you please provide more details? I have assumed that at the point
>>>>> of calling a function called p2m_destroy_altp2m_by_id() it should be
>>>>> safe to tear the altp2m down without further precaution.
>>>>
>>>> Are you absolutely positive that at this point there's no way anywhere
>>>> else in Xen might be doing something with this p2m struct?
>>>>
>>>> If so, then 1) there should be a comment there explaining why that's the
>>>> case, and 2) ideally we should refactor p2m_flush_table such that we can
>>>> call what's now p2m_flush_table_locked() without the lock.
>>>
>>> AFAICT the only place p2m_destroy_altp2m_by_id() is ever called is in
>>> arch/x86/hvm/hvm.c's do_altp2m_op() (on HVMOP_altp2m_destroy_p2m), which
>>> is done under domain lock. Is that insufficient?
>> 
>> Holding the domain lock does not imply nothing can happen to the
>> domain elsewhere. Only if both parties hold the _same_ lock there
>> is a guarantee of serialization between both.
> 
> Right, I was under the impression that for the duration of a HVMOP (or
> DOMCTL) nothing moves in the domain.

Well, if you need such behavior, you need to pause the domain (as
various domctl-s actually do).

Jan



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