On 29/03/2019 15:09, Juergen Gross wrote: > diff --git a/xen/common/schedule.c b/xen/common/schedule.c > index 9b5527c1eb..0b5e5e566b 100644 > --- a/xen/common/schedule.c > +++ b/xen/common/schedule.c > @@ -347,7 +347,7 @@ int sched_init_vcpu(struct vcpu *v) > if ( (item = sched_alloc_item(v)) == NULL ) > return 1; > > - if ( is_idle_domain(d) || d->is_pinned ) > + if ( is_idle_domain(d) ) > processor = v->vcpu_id; > else > processor = sched_select_initial_cpu(v);
This looks like a spurious change. I also don't an obvious other patch that it might fit into. As for the field itself, it is also fairly objectionable. It is only ever set for the hardware domain, and only if dom0_vcpus_pin is used, but the actual pinning information is also reflected in dom0's hard affinity mask. In practice, all this flag does is permit the use of VCPUOP_get_physid, disallow the use of vcpu_set_hard_affinity(), and allow dom0 to attempt to actually write to MSR_AMD64_NB_CFG, MSR_FAM10H_MMIO_CONF_BASE, MSR_IA32_UCODE_REV, MSR_IA32_THERM_CONTROL and MSR_IA32_ENERGY_PERF_BIAS, rather than having the write silently discarded. Dom0's use of those MSRs is dubious at best, and disabled by default, *and* when active, also cross-checks with the hard affinity mask. Does anyone use dom0_vcpus_pin in production? I think there is quite a lot of value in getting rid of d->is_pinned and is_pinned_vcpu() entirely, with will remove an extreme corner-case-x86-ism out of the common code. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
