From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aravind Gopalakrishnan Subject: Re: [PATCH] docs, amd_ucode: Add AMD container file format notes Date: Thu, 17 Jul 2014 14:50:08 -0500 Message-ID: <53C828F0.4010908@amd.com> References: <1405539035-25310-1-git-send-email-aravind.gopalakrishnan@amd.com> <53C802A3.1080008@oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <53C802A3.1080008@oracle.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Boris Ostrovsky , ian.campbell@citrix.com, ian.jackson@eu.citrix.com, jbeulich@suse.com, keir@xen.org, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 7/17/2014 12:06 PM, Boris Ostrovsky wrote: > >> + >> +The microcode container file format is as follows- >> +-------------+-----------------------------------------------+-------------------+------------------+------------------------------------------------------------+ >> >> +Name | Byte Offset | >> Length | Value | >> Description | >> +-------------+-----------------------------------------------+-------------------+------------------+------------------------------------------------------------+ >> >> +UCODE_MAGIC | 0 | >> 4 | MAGIC VAL | AMD UCODE MAGIC >> ID | >> +Type | 4 | >> 4 | 0 | 0 - Equivalence table, 1- >> Microcode patch | > > Description should say something like "Equivalence Table Type" (i.e. > since value is zero, this is not a patch) > Ok >> +Length | 8 | >> 4 | equiv_table_len1 | Length of equivalence table(1) >> bytes | >> + | Includes a terminating entry with all | >> + | zeroes (1 entry = 16 bytes) | > > Please describe somewhere equivalence table entry's format. > Pinged linux-firmware folks about including container format documentation. If that is OK with them, then maybe I should move this, and can also extend it to include equiv_table format.. >> +Equiv_table | 12 | >> equiv_table_len1 | - | Equivalence >> table | >> +Type | 12 + equiv_table_len1 | >> 4 | 1 | 0 - Equivalence table, 1- >> Microcode patch | > > "Microcode Patch Type" for description? > Ok >> +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 | > > Maybe mention somewhere patch's header format (i.e. struct > microcode_header_amd)? > > >> + . / >> + . \ >> + . / >> +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 | > > "last ucode patch" -> "Xth ucode patch". > Ok. (Although both pretty much convey same meaning in my head) >> +Patch | 28 + equiv_table_len1 + m(1) + ... + m(x-1) | >> m(x) | - | last ucode patch of >> container#1 | >> +-------------+-----------------------------------------------+-------------------+------------------+------------------------------------------------------------+ >> >> +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) | >> +-------------+-----------------------------------------------+-------------------+------------------+------------------------------------------------------------+ >> >> + . / >> + . \ >> + . / >> +-------------+-----------------------------------------------+-------------------+------------------+------------------------------------------------------------+ >> >> + >> >> +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 > > "Deadlock" doesn't sound like the best term here. You probably meant > that in cases where users are not sure about provenance of containers > they should obtain a "good" set since it's not guaranteed that the > latest patch will be applied? > > Yep. You provided a more accurate description here I think, so I shall blatantly copy your words if you don't have any objections:) -Aravind.