From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aravind Gopalakrishnan Subject: Re: [PATCH V3] x86, amd_ucode: Support multiple container files appended together Date: Thu, 26 Jun 2014 16:55:47 -0500 Message-ID: <53AC96E3.5050504@amd.com> References: <53AC43EF.807@oracle.com> <53AC4C60.7080206@amd.com> <53AC7BC4.6070902@oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <53AC7BC4.6070902@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 Cc: xen-devel@lists.xen.org, keir@xen.org, jbeulich@suse.com List-Id: xen-devel@lists.xenproject.org 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 - 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..) Thanks, -Aravind.