| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We do the microcode code update in two steps - the presmp:
'microcode_presmp_init' and when CPUs are brought up: 'microcode_init'.
The earlier performs the microcode update on the BSP - but
unfortunately it does not check whether the update failed. Which means
that we might try later to update a incorrect payload on the rest of
CPUs.
This patch handles this odd situation.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Keir Fraser <keir@xen.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Note: these changes don't make any difference on x86.
Replace XEN_GUEST_HANDLE with XEN_GUEST_HANDLE_PARAM when it is used as
an hypercall argument.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Keir Fraser <keir@xen.org>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
|
| |
|
|
|
| |
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In some cases guests should not provide workarounds for errata even when the
physical processor is affected. For example, because of erratum 400 on family
10h processors a Linux guest will read an MSR (resulting in VMEXIT) before
going to idle in order to avoid getting stuck in a non-C0 state. This is not
necessary: HLT and IO instructions are intercepted and therefore there is no
reason for erratum 400 workaround in the guest.
This patch allows us to present a guest with certain errata as fixed,
regardless of the state of actual hardware.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
Acked-by: Christoph Egger <Christoph.Egger@amd.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
Committed-by: Jan Beulich <jbeulich@suse.com>
|
| |
|
|
|
|
|
|
|
| |
... to indicate counting from the end of the modules list.
Suggested by Tim Deegan.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Largely as a result of the continuing resistance of Linux maintainers
to accept a microcode loading patch for pv-ops Xen kernels, this
follows the suggested route and provides a means to load microcode
updates without the assistance of Dom0, thus also addressing eventual
problems in the hardware much earlier.
This leverages the fact that via the multiboot protocol another blob
of data can be easily added in the form of just an extra module. Since
microcode data cannot reliably be recognized by looking at the
provided data, this requires (in the non-EFI case) the use of a
command line parameter ("ucode=<number>") to identify which of the
modules is to be parsed for an eventual microcode update (in the EFI
case the module is being identified in the config file, and hence the
command line argument, if given, will be ignored).
This required to adjust the XSM module determination logic accordingly.
The format of the data to be provided is the raw binary blob already
used for AMD CPUs, and the output of the intel-microcode2ucode utility
for the Intel case (either the per-(family,model,stepping) file or -
to make things easier for distro-s integration-wise - simply the
concatenation of all of them).
In order to not convert the spin_lock() in microcode_update_cpu() (and
then obviously also all other uses on microcode_mutex) to
spin_lock_irqsave() (which would be undesirable for the hypercall
context in which the function also runs), the boot time handling gets
done using a tasklet (instead of using on_selected_cpus()).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- memory was leaked on a CPU offline/online cycle (including S3)
- memory was leaked on AMD systems when microcode_update() ran a 2nd
time with the same data that was used on the first run
- microcode never got restored on APs during S3 resume (or post-boot
onlining of a CPU that was also online when microcode_update() first
ran [in the event the prior microcode update got lost intermediately,
which supposedly shouldn't happen]); this will still be the case when
no other online CPU has an identical signature (which however is now
consistent with bringing up such a CPU the very first time)
- resume was unimplemented in the AMD case
- there was a race between microcode_update_cpu() and
microcode_resume_cpu()
This also moves vendor specific type declarations to the vendor source
file and sets the stage for boot time microcode loading (i.e. without
Dom0 involvement).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
|
| |
|
|
|
|
|
|
| |
This includes the conversion from for_each_cpu_mask() to for_each-cpu().
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The former is the runtime equivalent of NR_CPUS (and users of NR_CPUS,
where necessary, get adjusted accordingly), while the latter is for the
sole use of determining the allocation size when dynamically allocating
CPU masks (done later in this series).
Adjust accessors to use either of the two to bound their bitmap
operations - which one gets used depends on whether accessing the bits
in the gap between nr_cpu_ids and nr_cpumask_bits is benign but more
efficient.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
|
| |
|
|
| |
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
|
| |
|
|
| |
Signed-off-by: Jan Beulich <jbeulich@novell.com>
|
| |
|
|
|
|
|
| |
When wakeup from S3, use per cpu microcode image to update cpu
microcode.
Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Update microcode logic:
1. separate microcode_fini_cpu() into 2 level to avoid deadlock (when
fail at microcode_update_cpu);
2. cancel redundant collect_cpu_info at microcode.c level, use
relative function at microcode driver level;
3. separate microcode_resume_cpu from microcode_update_cpu, because
it's redundant (should only be called when S3 wakeup) and will block newer
microcode update when user update newer microcode.dat from user level
Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
|
| |
|
|
|
|
|
| |
Cancel redundant input parameter 'uci', since it can get from another
input parameter 'cpu' as index.
Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Container header file holding the patches changed. Update to new
format.
- in cpu_request_microcode() move heap re-allocation & copy out of the
loop.
Side-effect: Remove limitation in only supporting fixed sized
microcode patches. Also simplifies code a lot.
- cleanup: use rdmsr and wrmsrl instead of inlined assembler
- pass ucode_cpu_info as arguments. Improves reentrancy.
- cleanup: simplify struct ucode_cpu_info and remove
get_matching_microcode hook. Side-effect: reduces kernel size.
- bugfix: fix xen kernel memory leak in error path. equiv_cpu_table
was not freed.
Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
|
| |
|
|
| |
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
|
| |
|
|
|
|
|
| |
It's unnecessary, and also invalid since the update process tries to
allocate memory.
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
|
| |
|
|
| |
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
|
| |
|
|
|
|
| |
(until allocations in irq context are fixed).
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
|
| |
|
|
|
|
|
| |
Microcode update support for AMD CPUs Family10h and Family11h.
It is based on a patch for Linux which is on its way for 2.6.28.
Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
|
| |
|
|
|
|
|
|
| |
Linux 2.6.27 marks the data pointer in its firmware struct 'const',
and hence, to avoid a compiler warning, Xen's microcode update
interface should be properly properly constified too.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A corresponding patch has gone into Linux 2.6.19; this is the
port to Xen.
Signed-off-by: Kurt Garloff <kurt@garloff.de>
Reference: Patch to linux kernel from Sep 27 2006
> # User Shaohua Li <shaohua.li@intel.com>
> # Node ID 45898b908138b5d93c2cc7353f061ce54af145dc
> # Parent f962eab7b82c9bf1a6da69571046e764f5128395
> [PATCH] x86 microcode: don't check the size
>
> IA32 manual says if micorcode update's size is 0, then the size is
> default size (2048 bytes). But this doesn't suggest all microcode
> update's size should be above 2048 bytes to me. We actually had a
> microcode update whose size is 1024 bytes. The patch just removed
> the check.
>
> Signed-off-by: Shaohua Li <shaohua.li@intel.com>
> Cc: Tigran Aivazian <tigran@veritas.com>
> Signed-off-by: Andrew Morton <akpm@osdl.org>
> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
>
> committer: Linus Torvalds <torvalds@g5.osdl.org> 1159370778 -0700
|
| |
|
|
|
|
|
| |
Confine the knowledge that the buffer gets accessed without use of
proper guest handle accessors to a single file.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
|
| |
|
|
|
| |
Signed-off-by: Steven Hand <steven@xensource.com>
|
| |
|
|
|
|
| |
Based on a patch from Jan Beulich.
Signed-off-by: Keir Fraser <keir@xensource.com>
|
| |
|
|
|
| |
Signed-off-by: Keir Fraser <keir@xensource.com>
|
| |
|
|
|
|
| |
Signed-off-by: Keir Fraser <keir@xensource.com>
|
| |
|
|
|
|
|
| |
Many files:
More include cleanups towards "include where it's used".
Signed-off-by: Christian Limpach <Christian.Limpach@cl.cam.ac.uk>
|
| |
|
|
|
|
|
|
|
|
| |
Many files:
More include cleanups towards "include where it's used".
sched.h:
g/c unneeded include.
include xen/spinlock.h once should be enough.
Signed-off-by: Christian Limpach <Christian.Limpach@cl.cam.ac.uk>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
sched.h:
g/c unneeded include.
Many files:
Rename xen/slab.h to xen/xmalloc.h and fix resulting fallout.
xmalloc.h:
Rename: xen/include/xen/slab.h -> xen/include/xen/xmalloc.h
sched.h, multicall.c, dom_mem_ops.c, asm-offsets.c:
cleanup incorrect includes.
Signed-off-by: Christian Limpach <Christian.Limpach@cl.cam.ac.uk>
|
| |
|
|
|
|
|
|
|
| |
Move to Linux's cpumask_t and 'hotplug' multi-processor booting
interfaces. This also brings apic.c and various other files closer to
their Linux 2.6 equivalents. Simplified the scheduler interfaces a
little (particularly per-cpu and idle-domain initialisation).
Signed-off-by: Keir Fraser <keir@xensource.com>
|
| |
|
|
|
|
|
| |
Phase 1 of upgrading platform code to be derived from Linux 2.6.11
rather than 2.4.x.
Signed-off-by: Keir Fraser <keir@xensource.com>
|
| |
|
|
|
|
| |
Add xmalloc_bytes() to the allocator API.
Signed-off-by: keir.fraser@cl.cam.ac.uk
|
| |
|
|
|
|
|
| |
Interface to typed allocator is now just xmalloc/xmalloc_array/xfree.
_xmalloc/_xmalloc_array are dead (or, at least, non-API).
Signed-off-by: keir.fraser@cl.cam.ac.uk
|
| |
|
|
|
|
|
| |
Introduce _xmalloc for when you really want just bytes.
Signed-off-by: ian.pratt@cl.cam.ac.uk
|
|
|
Add microcode driver to Xen.
|
