From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Aravind Gopalakrishnan <aravind.gopalakrishnan@amd.com>,
ian.campbell@citrix.com, ian.jackson@eu.citrix.com,
jbeulich@suse.com, keir@xen.org, xen-devel@lists.xen.org
Subject: Re: [PATCH] docs, amd_ucode: Add AMD container file format notes
Date: Thu, 17 Jul 2014 11:39:16 +0100 [thread overview]
Message-ID: <53C7A7D4.6070404@citrix.com> (raw)
In-Reply-To: <1405539035-25310-1-git-send-email-aravind.gopalakrishnan@amd.com>
On 16/07/14 20:30, Aravind Gopalakrishnan wrote:
> This patch introduces documentation notes about AMD container
> file formats and where to obtain latest container files from.
>
> Also, We provide a how-to for updating patch level by
> concatenating container files along with initrd images.
> Misc notes about how Xen handles two containers of same
> kind (if/when) they are concatenated together are also included.
>
> Signed-off-by: Aravind Gopalakrishnan <aravind.gopalakrishnan@amd.com>
Fantastic - documentation like this is very much appreciated.
A few questions inline...
> ---
> docs/misc/amd-ucode-container.txt | 123 +++++++++++++++++++++++++++++++++++++
> 1 file changed, 123 insertions(+)
> create mode 100644 docs/misc/amd-ucode-container.txt
>
> diff --git a/docs/misc/amd-ucode-container.txt b/docs/misc/amd-ucode-container.txt
> new file mode 100644
> index 0000000..975c02b
> --- /dev/null
> +++ b/docs/misc/amd-ucode-container.txt
> @@ -0,0 +1,123 @@
> +-------------------------------------------------
> +AMD Microcode Container File format
> +-------------------------------------------------
> +Author:
> + Aravind [dot] Gopalakrishnan [at] amd [dot] com
> +Created:
> + July 2014
> +-------------------------------------------------
> +
> +Intro to AMD Container Files:
> +-----------------------------
> +
> +* AMD provides microcode patch support for processors belonging to AMD
> + processor families 10h, 11h, 12h, 14h, and 15h.
> +* There is one single file (container file) containing all microcode patches
> + for AMD families 10h - 14h processors. [microcode_amd.bin]
> +* For AMD family 15h processors there is a separate container file. [microcode_amd_fam15h.bin]
> +* Microcode patches are not incremental, therefore you only need to make
> + sure you have the latest container file for your AMD processor family.
> +* One can find the latest AMD microcode containers from [2], [3]
> +
> +Mutual Exclusivity Rule of AMD containers:
> +* The patches for families 10h - 14h are guaranteed to be only on
> + microcode_amd.bin
> +* Similarly, patches for family 15h will only be on microcode_amd_fam15h.bin
> +* This is because, the processes and scripts used to create container files
> + ensure that there is no mix-up
> +
> +The microcode container file format is as follows-
> +-------------+-----------------------------------------------+-------------------+------------------+------------------------------------------------------------+
> +Name | Byte Offset | Length | Value | Description |
> +-------------+-----------------------------------------------+-------------------+------------------+------------------------------------------------------------+
> +UCODE_MAGIC | 0 | 4 | MAGIC VAL | AMD UCODE MAGIC ID |
What is MAGIC VAL ?
> +Type | 4 | 4 | 0 | 0 - Equivalence table, 1- Microcode patch |
> +Length | 8 | 4 | equiv_table_len1 | Length of equivalence table(1) bytes |
> + | Includes a terminating entry with all |
> + | zeroes (1 entry = 16 bytes) |
Does this mean that equiv_table_len1 is in units of 16 bytes, or that it
is guaranteed to be a multiple of 16?
> +Equiv_table | 12 | equiv_table_len1 | - | Equivalence table |
> +Type | 12 + equiv_table_len1 | 4 | 1 | 0 - Equivalence table, 1- Microcode patch |
> +Length | 16 + equiv_table_len1 | 4 | m(1) | Length of 1st ucode patch in bytes |
> +Patch | 20 + equiv_table_len1 | m(1) | - | 1st ucode patch |
> + . /
> + . \
> + . /
> +Type | 20 + equiv_table_len1 + m(1) + ... + m(x-1) | 4 | 1 | 0 - Equivalence table, 1- Microcode patch |
> +Length | 24 + equiv_table_len1 + m(1) + ... + m(x-1) | 4 | m(x) | Length of last ucode patch of this container#1 in bytes |
> +Patch | 28 + equiv_table_len1 + m(1) + ... + m(x-1) | m(x) | - | last ucode patch of container#1 |
So judging from the above, an individual container is made up of a magic
value followed by a number of type/length/data blobs.
Type can be one of equivalence table or microcode patch, and there are
multiple microcode patches per equivalence table?
It might be better to express it like that, as the calculation for byte
offset gets quite complicated quite quickly.
~Andrew
> +-------------+-----------------------------------------------+-------------------+------------------+------------------------------------------------------------+
> +UCODE_MAGIC | 28 + equiv_table_len1 + m(1) + ... + m(x) | 4 | MAGIC VAL | AMD UCODE MAGIC ID (container#2 starts here) |
> +Type | 32 + equiv_table_len1 + m(1) + ... + m(x) | 4 | 0 | 0 - Equivalence table, 1- Microcode patch |
> +Length | 36 + equiv_table_len1 + m(1) + ... + m(x) | 4 | equiv_table_len2 | Length of equivalence table(2) in bytes |
> + | Includes a terminating entry with all |
> + | zeroes (1 entry = 16 bytes) |
> +Equiv_table | 40 + equiv_table_len1 + m(1) + ... + m(x) | equiv_table_len2 | - | Equivalence table |
> +Type | 40 + equiv_table_len1 + m(1) + ... + m(x) | 4 | 1 | 0 - Equivalence table, 1- Microcode patch |
> + + equiv_table_len2 |
> +Length | 44 + equiv_table_len1 + m(1) + ... + m(x) | 4 | n(1) | Length of 1st ucode patch in bytes |
> + + equiv_table_len2 |
> +Patch | 48 + equiv_table_len1 + m(1) + ... + m(x) | n(1) | - | 1st ucode patch |
> + + equiv_table_len2 |
> + . /
> + . \
> + . /
> +Type | 48 + equiv_table_len1 + m(1) + ... + m(x) | 4 | 1 | 0 - Equivalence table, 1- Microcode patch |
> + + equiv_table_len2 + ... + n(y-1) |
> +Length | 52 + equiv_table_len1 + m(1) + ... + m(x) | 4 | n(y) | Length of last ucode patch of this container in bytes |
> + + equiv_table_len2 + ... + n(y-1) |
> +Patch | 56 + equiv_table_len1 + m(1) + ... + m(x) | n(y) | - | last ucode patch of container#2 |
> + + equiv_table_len2 + ... + n(y) |
> +-------------+-----------------------------------------------+-------------------+------------------+------------------------------------------------------------+
> + . /
> + . \
> + . /
> +-------------+-----------------------------------------------+-------------------+------------------+------------------------------------------------------------+
> +
> +Apply microcode updates using initrd:
> +-------------------------------------
> +Initrd images can be modified to contain AMD microcode containers in cpio
> +format at the start of the image.
> +Following example shows how to generate a combined initrd
> +Note: initrd-<val> could be different on your machine. Substitute accordingly
> +Example System base: Ubuntu 13.04 with 3.8.0-30-generic kernel
> +1. mkdir initrd-for-xen-with_append
> +2. cd initrd-for-xen-with_append
> +3. mkdir -p kernel/x86/microcode
> +4. cp /lib/firmware/amd-ucode/microcode_amd.bin .
> +5. cp /lib/firmware/amd-ucode/microcode_amd_fam15h.bin .
> +6. cat microcode_amd.bin microcode_amd_fam15h.bin > microcode_concatenated.bin
> +7. mv microcode_concatenated.bin kernel/x86/microcode/AuthenticAMD.bin
> +8. rm microcode_amd.bin microcode_amd_fam15h.bin
> +9. find . | cpio -o -H newc > ucode.cpio
> +10. cp /boot/initrd.img-3.8.0-30-generic .
> +11. cat ucode.cpio initrd.img-3.8.0-30-generic > initrd_for_xen_with_ucode
> +12. cp initrd_for_xen_with_ucode /boot/
> +13. On grub.cfg, provide the above initrd name as module.
> +14. Use 'ucode=scan' option as Xen boot parameter.
> +
> +Misc Notes:
> +-----------
> +It is not recommended to concatenate two(or more) container files of
> +the same kind. (two microcode_amd_fam15h.bin for example)
> +This is because:
> +There is no check in Xen currently to verify this.
> +Now, given a situation where
> +1. An earlier container has a patch that 'fits' the processor you are
> + currently on,
> +2. There is a subsequent container that *also* has a patch that 'fits',
> +3. The second patch happens to be an update over the patch found on the
> + first container file.
> +
> +In such a case, only the patch from the first container is applied.
> +This is because Xen assumes that the the containers (if concatenated
> +together) are different kinds AND the 'Mutual Exclusivity' rule is
> +always true.
> +
> +On such cases of deadlock, it is preferable to update the microcode container
> +files first using distro specific methods or downloading them from [2], [3].
> +
> +Reference(s):
> +-------------
> +[1] http://lxr.free-electrons.com/source/Documentation/x86/early-microcode.txt
> +[2] http://www.amd64.org/microcode.html
> +[3] https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tree/amd-ucode
next prev parent reply other threads:[~2014-07-17 10:39 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-16 19:30 [PATCH] docs, amd_ucode: Add AMD container file format notes Aravind Gopalakrishnan
2014-07-17 10:39 ` Andrew Cooper [this message]
2014-07-17 15:44 ` Aravind Gopalakrishnan
2014-07-17 17:06 ` Boris Ostrovsky
2014-07-17 19:50 ` Aravind Gopalakrishnan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53C7A7D4.6070404@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=aravind.gopalakrishnan@amd.com \
--cc=ian.campbell@citrix.com \
--cc=ian.jackson@eu.citrix.com \
--cc=jbeulich@suse.com \
--cc=keir@xen.org \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).