[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH V3] x86, amd_ucode: Support multiple container files appended together

On 06/26/2014 05:55 PM, Aravind Gopalakrishnan wrote:
On 6/26/2014 3:00 PM, Boris Ostrovsky wrote:

The process(,scripts) to create containers ensure that we only have patches for f10h-f14h on 'microcode_amd.bin' and patches for f15h models (could be different model/stepping values) on microcode_amd_fam15h.bin

So it is safe to assume that we we only have a matching equiv_id in only one of the containers.

The trouble is that if I have two files in my hands, both called microcode_amd_fam15h.bin, I don't know which one is the more up-to-date (would be nice to have a tool to print file info).

Of course, one can argue that in that case I shouldn't be using neither but HW makes its own verification of patches so in principle trying both should be safe (provided that SW tries not to load older revision).

Hmm, yeah... But this is a pretty contrived case and I'm still not completely convinced this is something we should handle..
Here are my thoughts:
- If such a case arises, one can just pull the latest containers which are published - here: https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tree/amd-ucode
  - and here: http://www.amd64.org/microcode.html
- distros also keep themselves updated by pulling the binaries from above links - We can add documentation notes stating to the effect that users(sysadmins) are better off not concatenating two containers of same processor family. - It won't break anything, but you just might end up on a not-so-latest microcode patch level

AFAIK the code always picks the latest version of the patch.

  - And also point to above links to resolve such deadlock situations
- If you would still prefer that we handle this case, then we probably should not do it as you described. - The proper way would be to go back to the start of the 1st while loop. - Because we can go back to find_equiv_cpu_id() and take things from there again..
    - So, more logic rework..
(I'm ok with re-working the code, but do let me know if this a case we should care for..)

I think it's worth doing.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.