Re: [Xen-ia64-devel] Some things to be considered for ptc.ga emulation

[Tristan Gingold <Tristan.Gingold@xxxxxxxx>]

Le Mercredi 05 Avril 2006 07:07, Tian, Kevin a écrit :
> Some in my mind, and welcome comments. :-)
>
> 0. The goal of ptc.ga emulation?
>       Quick efficient, negligible influence to other path, clean to
> avoid corner cases as possible...
Sure :-)

> 1. Does ptc.ga emulation need to wait until other vcpus completes?
>       If no wait, multiple emulation request may pend thus need extra
> structures to track with lock protection.
>       If no wait, it may break guest's assumption that effect should
> be
> observed by other vcpus after pta.ga loop.
>       If wait, need evaluate how long the emulation will last under
> worst
> case.
>
>       Suggestion: Go wait policy first which is clean, and later may
> consider enhancement with "no wait".
>
> 2. Is it easy to change context on a different LP directly?
>       [vTLB], per vcpu resource:
>               Need to check whether target vcpu is accessing the vTLB
> with
> lock required. Current code is problematic:
>                       * That lock is not a seqlock since both sides
> need to hold
> the lock
>                       * Only vcpu_translate stamps tlb_inuse count
> now.
> However all places with access needs same lock sense like tlb insertion
> emulation.
I am not sure about that.
If both are writing, we can have incomplete insertion (eg: only dtlb but no 
vhpt nor itc), but it shouldn't matter.


>                       * Lack of region id information. For a hash
> version tlb, need
> region id to calculate hash value of target entry. Since in different
> context, region id switch is still required.
Unless this is done in the context of the cpu doing ptc.ga.

>               A bit complex and corner cases may exist
>
>       [VHPT], now a per LP resource for para-domain:
>               It's dangerous to change VHPT on another LP directly,
> without
> lock. However once adding the lock, the code becomes complex and
> efficiency of normal path is affected. Considering most VHPT walk is
> done in light weight assembly code...
Sure.

>       Suggestion: it's natural/efficient to issue IPI to flush VHPT
> table of
> other LPs. If that's the case, why not integrate vcpu purge together
> with IPI?
Natural yes, efficient not sure.

> 3. How to handle target vcpu in running state?
>       If interrupted context by IPI is one of the target domain, set a
> bit in
> current vcpu and vtlb/vhpt purge will be done right before resuming back
> to guest. This can ensure no race condition.
>
>       If interrupted context by IPI is not target domain, it means
> it's always
> safe to operate vtlbs of target vcpus queued on this LP. In this case,
> directly purge all target vtlbs on current LP, and yes region id change
> is also required to get hash value

> 4. How long does ptc.ga emulation need to wait?
>       By above IPI style, the best case is that all target vcpus are
> not in
> running state and thus all emulation work can be done within IPI handler
>
>       The worst case is that target vcpu is in running state. In that
> case,
> extra time is added between IPI handler and the point resuming back to
> guest. But that extra time is normally short and tolerable.
>
>       Then the whole emulation can always ensure all other vcpus
> observe the effect before resuming back to guest.
>
> That's the flow in my mind about this thread. :-)
I think this describes correctly the IPI way.

BTW, I am still working on direct purge.

Tristan.



_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel