On 29/03/2019 20:36, Andrew Cooper wrote: > 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.
That should be in patch 30. > 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. Right. > 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 have seen it on customer systems. > 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. Right. I don't see a reason why we need anything else but the hard affinity for this option. Allowing to re-pin (or unpin) vcpus should be fine. And use of the said MSRs could be restricted to the correct hard affinity being active. Juergen _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
