The Linux kernel is able to update the microcode during early bootup
via inspection of the initramfs blob to see if there is an cpio image
with certain microcode files. Linux is able to function with two (or
more) cpio archives in the initrd b/c it unpacks all of the cpio
archives.
The format of the early initramfs is nicely documented in Linux's
Documentation/x86/early-microcode.txt:
Early load microcode
====================
By Fenghua Yu <fenghua.yu@intel.com>
Kernel can update microcode in early phase of boot time. Loading microcode early
can fix CPU issues before they are observed during kernel boot time.
Microcode is stored in an initrd file. The microcode is read from the initrd
file and loaded to CPUs during boot time.
The format of the combined initrd image is microcode in cpio format followed by
the initrd image (maybe compressed). Kernel parses the combined initrd image
during boot time. The microcode file in cpio name space is:
kernel/x86/microcode/GenuineIntel.bin
During BSP boot (before SMP starts), if the kernel finds the microcode file in
the initrd file, it parses the microcode and saves matching microcode in memory.
If matching microcode is found, it will be uploaded in BSP and later on in all
APs.
The cached microcode patch is applied when CPUs resume from a sleep state.
There are two legacy user space interfaces to load microcode, either through
/dev/cpu/microcode or through /sys/devices/system/cpu/microcode/reload file
in sysfs.
In addition to these two legacy methods, the early loading method described
here is the third method with which microcode can be uploaded to a system's
CPUs.
The following example script shows how to generate a new combined initrd file in
/boot/initrd-3.5.0.ucode.img with original microcode microcode.bin and
original initrd image /boot/initrd-3.5.0.img.
mkdir initrd
cd initrd
mkdir kernel
mkdir kernel/x86
mkdir kernel/x86/microcode
cp ../microcode.bin kernel/x86/microcode/GenuineIntel.bin
find .|cpio -oc >../ucode.cpio
cd ..
cat ucode.cpio /boot/initrd-3.5.0.img >/boot/initrd-3.5.0.ucode.img
As such this code inspects the initrd to see if the microcode
signatures are present and if so updates the hypervisor.
The option to turn this scan on/off is gated by the 'ucode'
parameter. The options are now:
'scan' Scan for the microcode in any multiboot payload.
<index> Attempt to load microcode blob (not the cpio archive
format) from the multiboot payload number.
This option alters slightly the 'ucode' parameter by only allowing
either parameter:
ucode=[<index>|scan]
Implementation wise the ucode_blob is defined as __initdata.
That is OK from the viewpoint of suspend/resume as the the underlaying
architecture microcode (microcode_intel or microcode_amd) end up saving
the blob in 'struct ucode_cpu_info' which is a per-cpu data
structure (see ucode_cpu_info). They end up saving it when doing the
pre-SMP (for CPU0) and SMP (for the rest) microcode loading.
Naturally if one does a hypercall to update the microcode and it is
newer, then the old per-cpu data is replaced.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Acked-by: Keir Fraser <keir@xen.org>
The BIOS reboot option was never implemented for x86_64, and retaining
it is somewhat false advertising.
Signed-off-by: Matt Wilson <msw@amazon.com>
Acked-by: Keir Fraser <keir@xen.org>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
With there being so many systems with broken ACPI tables, and with it
generally being known what's wrong with those tables, give people a
handle to overcome the resulting disabling of their IOMMUs.
Inspired by Linux side patches providing similar functionality.
Suggested-by: Sander Eikelenboom <linux@eikelenboom.it>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Tested-By: Sander Eikelenboom <linux@eikelenboom.it>
Acked-by: Keir Fraser <keir@xen.org>
Acked-by: Suravee Suthikulpanit <suravee.suthikulapanit@amd.com>
The Cyclone time source was part of IBM's Summit chipset, which was
only used for 32-bit only ccNUMA and IA-64 machines. Neither of these
are supported by Xen anymore.
Signed-off-by: Matt Wilson <msw@amazon.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
IBM's Summit chipset was only used for 32-bit only Intel ccNUMA and
IA-64 machines, neither of which are supported by Xen anymore.
Signed-off-by: Matt Wilson <msw@amazon.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
- force use of physical APIC mode if indicated so (as we don't support
xAPIC cluster mode, the respective flag is taken to force physical
mode too)
- don't use MSI if indicated so (implies no IOMMU)
Both can be overridden on the command line, for the MSI case this at
once adds a new command line option allowing to turn off PCI MSI (IOMMU
and HPET are unaffected by this).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
At least certain Marvell SATA controllers are known to issue bus master
requests with a non-zero function as origin, despite themselves being
single function devices.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: "Zhang, Xiantao" <xiantao.zhang@intel.com>
The sched_credit_default_yield option was added when the behavior of
"SCHEDOP_yield" was changed in 4.1, to allow any users who had
problems to revert to the old behavior. The new behavior has been in
Xen.org xen since 4.1, and in XenServer even longer, and there is no
evidence of anyone having trouble with it. Remove the option.
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
Committed-by: Keir Fraser <keir@xen.org>
This is a port of Linux'es intel-idle driver serving the same purpose.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
Allow intermediate parts of the command line options to be absent
(expressed by two immediately succeeding commas).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
The dom0_max_vcpus command line option only allows the exact number of
VCPUs for dom0 to be set. It is not possible to say "up to N VCPUs
but no more than the number physically present."
Allow a range for the option to set a minimum number of VCPUs, and a
maximum which does not exceed the number of PCPUs.
For example, with "dom0_max_vcpus=4-8":
PCPUs Dom0 VCPUs
2 4
4 4
6 6
8 8
10 8
Existing command lines with "dom0_max_vcpus=N" still work as before
(and are equivalent to dom0_max_vcpus=N-N).
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Committed-by: Jan Beulich <jbeulich@suse.com>
I'm sure they aren't perfect but various people have done a pass over
them recently and they are much improved. I don't think we need to
continue to describe them so pessimistically.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
This change improves documentation for several Xen command line
parameters. Some of the Itanium-specific options are now removed. A
more thorough check should be performed to remove any other remnants.
I've reformatted some of the entries to fit in 80 column terminals.
Options that are yet undocumented but accept standard boolean /
integer values are now annotated as such.
The size suffixes have been corrected to use the binary prefixes
instead of decimal prefixes.
Signed-off-by: Matt Wilson <msw@amazon.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
grep claims that all of these command line arguments no longer exist
in the xen source tree.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Committed-by: Keir Fraser <keir@xen.org>
Some for readability, and some to escape underscores.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Committed-by: Keir Fraser <keir@xen.org>
Processors with this erratum are subject to a DoS attack by unprivileged
guest users.
This is XSA-9 / CVE-2012-2934.
Signed-off-by: Jan Beulich <JBeulich@suse.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
Add a short description to the vpmu boot option in the
xen-command-line.markdown
Signed-off-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
Committed-by: Ian Jackson <ian.jackson.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
This addresses Ian C's comments on v1 of a previous patch (which
was applied instead of v2).
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
Run a spell checker over the doc and fix the typos and spelling it uncovers
(including a few I just added myself).
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Jackson <ian.jackson.citrix.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
These were mostly ones from xen/arch/x86/boot/cmdline.S which are handled early
and therefore do not use the usual infrastructure and so got missed in the
initial trawl.
The document now contains (AFAICT) every still valid option which was
previously documented at:
http://wiki.xen.org/wiki?title=Xen_Hypervisor_Boot_Options&oldid=1379
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Jackson <ian.jackson.citrix.com>
On 64bit Xen with 32bit dom0 and crashkernel, xmalloc'ing items such
as the CPU crash notes will go into the xenheap, which tends to be in
upper memory. This causes problems on machines with more than 64GB
(or 4GB if no PAE support) of ram as the crashkernel physically cant
access the crash notes.
The solution is to force Xen to allocate certain structures in lower
memory. This is achieved by introducing two new command line
parameters; low_crashinfo and crashinfo_maxaddr. Because of the
potential impact on 32bit PV guests, and that this problem does not
exist for 64bit dom0 on 64bit Xen, this new functionality defaults to
the codebase's previous behavior, requiring the user to explicitly
add extra command line parameters to change the behavior.
This patch consists of 3 logically distinct but closely related
changes.
1) Add the two new command line parameters.
2) Change crash note allocation to use lower memory when instructed.
3) Change the conring buffer to use lower memory when instructed.
There result is that the crash notes and console ring will be placed
in lower memory so useful information can be recovered in the case of
a crash.
Changes since v1:
- Patch xen-command-line.markdown to document new options
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Committed-by: Keir Fraser <keir@xen.org>
Introduce a command parameter to set the watchtog timeout. Manually
specifying "watchdog_timeout=<seconds>" on the command line will also
turn the watchdog on. For consistency, move opt_watchdog into nmi.c
along with opt_watchdog_timeout.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Committed-by: Keir Fraser <keir@xen.org>
Still a work in progress, but submitted as a start.
Changes since v1:
- Include all up to date information from the wiki.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Keir Fraser <keir@xen.org>
Andrew Cooper
Konrad Rzeszutek Wilk
Matt Wilson
Jan Beulich
Ian Campbell
George Dunlap
David Vrabel
Tim Deegan
Dietmar Hahn