xen/credit2: let the tickled pCPU pick up the unit it was tickled for

runq_tickle() picks an idle pCPU without taking CSCHED2_MIGRATE_RESIST
into account, but runq_candidate() on that pCPU still applies it. With
the unit's credit within CSCHED2_MIGRATE_RESIST of CSCHED2_CREDIT_MIN,
the tickled pCPU declines the unit because it is not its master, while
the master has already skipped it as deferred to the tickled pCPU. Both
go idle and the unit stays runnable on the runqueue with nobody to run
it.

Seen as a permanent PVH dom0 stall under nested virtualization, where
dom0 overruns its slice far enough to be clamped at CSCHED2_CREDIT_MIN.

Don't resist migration to the pCPU that was tickled for the unit.

Fixes: 069cf39fb1 ("xen: credit2: make tickling more deterministic")
Signed-off-by: Jiaqing Zhao <Zhao.Jiaqing@amd.com>
Reviewed-by: George Dunlap <gwd@xenproject.org>
Reviewed-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>

xen/common/sched/credit2.c

@@ -3514,9 +3514,11 @@ runq_candidate(struct csched2_runqueue_data *rqd,
 
         /*
          * If this is on a different processor, don't pull it unless
-         * its credit is at least CSCHED2_MIGRATE_RESIST higher.
+         * its credit is at least CSCHED2_MIGRATE_RESIST higher, or the
+         * processor was tickled for it.
          */
         if ( sched_unit_master(svc->unit) != cpu
+             && svc->tickled_cpu != cpu
              && snext->credit + CSCHED2_MIGRATE_RESIST > svc->credit )
         {
             SCHED_STAT_CRANK(migrate_resisted);