[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:
On 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.
My thought was using a command line parameter to toggle whether we need
debug messages to be printed or not
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
|
