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

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

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

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

        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?

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

Thanks,
Kevin

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