Re: [Xen-devel] [PATCH] xen: schedule: allow dom0 vCPUs to be re-pinned when dom0_vcpus_pin is set

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 10.12.12 at 23:01, Matt Wilson <msw@xxxxxxxxxx> wrote:
> So today if I boot Xen without dom0_vcpus_pin set, dom0's vCPUs will
> be allowed to run on any pCPU. Xen will block attempts to write
> certain MSRs (MSR_AMD64_NB_CFG, MSR_FAM10H_MMIO_CONF_BASE and
> MSR_IA32_ENERGY_PERF_BIAS). The VCPUOP_get_physid subop of the vcpu_op
> hypercall will not return the initial APIC ID or ACPI ID for dom0.
> 
> Also today, if I run "xl vcpu-pin 0 0", suddenly those MSR writes and
> the VCPUOP_get_physid hypercall will start working for vCPU 0. For

Exactly as intended.

> what it's worth, only legacy XenoLinux-derived kernels appear to use
> this hypercall during SMP boot. Upstream Linux does not.

Because that's being used for the "cpufreq=dom0" case, which I
don't think the pv-ops kernel really ever tried to support.

> I think that the real risk is in the XenoLinux SMP booting code on AMD
> processors where sometimes initial APIC ID != ACPI ID. If the CPU
> pinning changes, the ACPI ID to APIC ID mapping will be wrong. This
> broke PowerNow! when it ran in dom0.
> 
> But PowerNow! is handled by the hypervisor now. So what's the real
> danger here?

I never liked the idea of "cpufreq=dom0", and our kernels
intentionally make it impossible to be used (i.e. much like
pv-ops). But for there potentially being people wanting this, we
can't simply rip it out.

The real danger is with exactly what you describe - a careless
caller using the result of any of the then possible operations in
a context where they're not valid anymore.

And there are use cases outside of Dom0-based power
management: If carefully done, this allows implementation of
a kernel driver (extension) similar to x86's msr.ko, allowing
access to the physical CPU's MSRs. And properly implementing
the dcdbas, coretemp, and via-cputemp drivers.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel