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

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

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


Xen-devel mailing list



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