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