Re: Xen timecounter issues

["Mathew, Cherry G." <c%bow.st@localhost>]

>>>>> On Mon, 24 Jun 2024 12:00:25 +0200, Manuel Bouyer <bouyer%antioche.eu.org@localhost> said:

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

I'm not - I may have misread Brad's email. 


-- 
Math/(~cherry)