Re: Xen timecounter issues

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Mon, Jun 24, 2024 at 09:55:44AM +0000, Mathew, Cherry G. wrote:
> >>>>> On Mon, 24 Jun 2024 11:48:50 +0200, Manuel Bouyer <bouyer%antioche.eu.org@localhost> said:
> 
> > On Mon, Jun 24, 2024 at 09:39:32AM +0000, Mathew, Cherry G. wrote:
> >> >>>>> On Mon, 24 Jun 2024 11:30:14 +0200, Manuel Bouyer <bouyer%antioche.eu.org@localhost> said:
> >> 
> >> [...]
> >> 
> >> >> else if ( pv_shim && v->vcpu_id == 0 )
> >> >> {
> >> >> /*
> >> >> * PV-shim: vcpus are pinned 1:1. Initially only 1 cpu is online,
> >> >> * others will be dealt with when onlining them. This avoids pinning
> >> >> * a vcpu to a not yet online cpu here.
> >> >> */
> >> >> sched_set_affinity(unit, cpumask_of(0), cpumask_of(0));
> >> 
> >> [...]
> >> 
> >> 
> >> > But this doens't tell anything about CPU 0 ?
> >> 
> >> It does - that's the first part of the if clause. So in the UP case,
> >> vcpu0 is pinned to pcpu0 - which is probably why this doesn't show up in
> >> the dom0/UP case.
> 
> > The first part of the if clause is about pv_shim, which is not in use for dom0
> > AFAIK the part of the if clause will be taken only for domUs started with
> > type="pvh"
> > pvshim=1
> 
> > and this will never be the case for dom0
> 
> Oh, I assumed that pvshim was for PV hypervisor emulation (not sure why
> I got that impression).
> 
> This opens up the question of why the TSC bug doesn't appear in the
> dom0/UP case, without explicit vCPU pinning then.

Are you sure it doens't happens in this case ? I'm not seeing the problem
even in the SMP case ...

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--