[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH V2] x86, amd_ucode: Verify max allowed patch size before apply
On 4/30/2014 1:07 AM, Jan Beulich wrote: My thought was using a command line parameter to toggle whether we need debug messages to be printed or notOn 30.04.14 at 01:56, <aravind.gopalakrishnan@xxxxxxx> wrote:On 4/29/2014 4:33 PM, Aravind Gopalakrishnan wrote:On 4/29/2014 3:02 AM, Jan Beulich wrote:@@ -123,8 +151,17 @@ static bool_t microcode_fits(const struct microcode_amd *mc_amd, int cpu) if ( (mc_header->processor_rev_id) != equiv_cpu_id ) return 0; + if ( !verify_patch_size(mc_amd->mpb_size) ) + { + printk(XENLOG_DEBUG "microcode: patch size mismatch\n"); + return -E2BIG; + } + if ( mc_header->patch_id <= uci->cpu_sig.rev ) - return 0; + { + printk(XENLOG_DEBUG "microcode: patch is already at required level or greater.\n"); + return -EEXIST; + } printk(KERN_DEBUG "microcode: CPU%d found a matching microcode " "update with version %#x (current=%#x)\n",Honestly I'm rather hesitant to accept further generally useless messages, no matter that they get printed at KERN_DEBUG only. I'd much rather see these as well as the existing ones to be converted to pr_debug(), thus easily enabled if someone really needs to do debugging here. That's mainly because I (and I suppose other developers do so to) try to run with loglvl=all wherever possible, yet already on the 2x4-core box (not to speak of the newer 2x12- core one) I find these rather annoying.Hmm, Okay. I'll work on this and send an updated version..couple of ideas about implementing this:Actually I'd prefer to just go the microcode_intel.c route for now, unless there's a compelling reason for something more involved. is easier still than having to change #define pr_debug and recompile.. Anyway, I shall use microcode_intel's method then.. -Aravind. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |