Like Intel, AMD also records the date in their blobs. The field was
merely misnamed as "data_code" so far; this was perhaps meant to be
"date_code". Split it into individual fields, just like we did for Intel
some time ago, and extend the message logged after a successful update.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/cpu/microcode/amd.c
+++ b/xen/arch/x86/cpu/microcode/amd.c
@@ -33,7 +33,9 @@ struct equiv_cpu_entry {
 };
 
 struct microcode_patch {
-    uint32_t data_code;
+    uint16_t year;
+    uint8_t  day;
+    uint8_t  month;
     uint32_t patch_id;
     uint8_t  mc_patch_data_id[2];
     uint8_t  mc_patch_data_len;
@@ -251,8 +253,9 @@ static int apply_microcode(const struct
         return -EIO;
     }
 
-    printk(XENLOG_WARNING "microcode: CPU%u updated from revision %#x to %#x\n",
-           cpu, old_rev, rev);
+    printk(XENLOG_WARNING
+           "microcode: CPU%u updated from revision %#x to %#x, date = %04x-%02x-%02x\n",
+           cpu, old_rev, rev, patch->year, patch->month, patch->day);
 
     return 0;
 }

On 01/04/2021 09:28, Jan Beulich wrote:
> Like Intel, AMD also records the date in their blobs. The field was
> merely misnamed as "data_code" so far; this was perhaps meant to be
> "date_code". Split it into individual fields, just like we did for Intel
> some time ago, and extend the message logged after a successful update.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>

This was on my todo list, but I'd not got around to it yet.  There are
several legitimate microcode blobs with incorrect dates.

One has a date with a year earlier than its predecessor or successor,
and two have day/month transpositions.  One transposition is obvious,
having a 13 in it, while the other is ambiguous and guessed based on
when the ucode was available.

I wasn't going to bother doing anything about this, but it is something
to be aware of if we get queries of wonky looking dates.

~Andrew