All of lore.kernel.org
 help / color / mirror / Atom feed
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Atom2 <ariel.atom2@web2web.at>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	daniel.kiper@oracle.com, david.vrabel@citrix.com,
	Jan Beulich <JBeulich@suse.com>,
	Yang Z Zhang <yang.z.zhang@intel.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	boris.ostrovsky@oracle.com
Subject: Re: How many patches are missing in upstream Linux?
Date: Wed, 12 Mar 2014 09:50:22 -0400	[thread overview]
Message-ID: <20140312135022.GC3245@phenom.dumpdata.com> (raw)
In-Reply-To: <53204BD5.6090602@web2web.at>

[-- Attachment #1: Type: text/plain, Size: 3073 bytes --]

On Wed, Mar 12, 2014 at 12:58:13PM +0100, Atom2 wrote:
> 
> 
> Am 12.03.14 12:42, schrieb Jan Beulich:
> >>>>On 12.03.14 at 12:14, Atom2 <ariel.atom2@web2web.at> wrote:
> >>Am 12.03.14 09:20, schrieb Jan Beulich:
> >>dmesg1 - that's the one where the update works
> >>(XEN) Command line: placeholder ucode=-1 vga=gfx-1024x768x32 i915.mod |
> >
> >No notion of "loglvl=all" here.
> That's because the output from sdiff is limited in width - so here
> you go with the complete command line as reported by xl dmesg for
> the ucode=1- case:
> 
> (XEN) Command line: placeholder ucode=-1 vga=gfx-1024x768x32
> i915.modeset=1 loglvl=all guest_loglvl=all dom0_mem=4G,max:4G tmem=1
> tm
> em_compress=1 tmem_dedup=1 dom0_max_vcpus=8 dom0_vcpus_pin=true
> cpufreq=xen cpuidle clocksource=hpet iommu=1 sched_credit_tsclice_ms
> =5 bootscrub=0
> >
> >>dmesg2 - that's the one where the update doesn't work
> >>| (XEN) Command line: placeholder ucode=scan vga=gfx-1024x768x32 i915.m
> >
> >Nor here.
> And here for the ucode=scan case:
> 
> (XEN) Command line: placeholder ucode=scan vga=gfx-1024x768x32
> i915.modeset=1 loglvl=all guest_loglvl=all dom0_mem=4G,max:4G tmem=1
> tmem_compress=1 tmem_dedup=1 dom0_max_vcpus=8 dom0_vcpus_pin=true
> cpufreq=xen cpuidle clocksource=hpet iommu=1 sched_credit_tsclice_
> ms=5 bootscrub=0

I am still not sure why it does not work for you but it works for me so
perhaps:

a) the cpio archive is not being parsed by the 'ucode=scan' code.
   The patch attached can help in narrowing that possibility.

b). The blobs are corrupted (also the patch below should help with that).

c). Somethng else :-)

Could you kindly try the attached patch? That should help in figuring out
one of these options above.

You should see something like this (this is on a SandyBridge) if it works:

$xl dmesg | grep -i microcode
(XEN) microcode payload @1 found (576512)
(XEN) microcode: collect_cpu_info : sig=0x206a7, pf=0x2, rev=0x28
(XEN) microcode: CPU0 found a matching microcode update with version 0x29 (current=0x28)
(XEN) microcode: CPU0 updated from revision 0x28 to 0x29, date = 2013-06-12 
(XEN) microcode: collect_cpu_info : sig=0x206a7, pf=0x2, rev=0x28
(XEN) microcode: CPU1 found a matching microcode update with version 0x29 (current=0x28)
(XEN) microcode: CPU1 updated from revision 0x28 to 0x29, date = 2013-06-12 
(XEN) microcode: collect_cpu_info : sig=0x206a7, pf=0x2, rev=0x28
(XEN) microcode: CPU3 found a matching microcode update with version 0x29 (current=0x28)
(XEN) microcode: CPU3 updated from revision 0x28 to 0x29, date = 2013-06-12 
(XEN) microcode: collect_cpu_info : sig=0x206a7, pf=0x2, rev=0x29
(XEN) microcode: collect_cpu_info : sig=0x206a7, pf=0x2, rev=0x28
(XEN) microcode: CPU2 found a matching microcode update with version 0x29 (current=0x28)
(XEN) microcode: CPU2 updated from revision 0x28 to 0x29, date = 2013-06-12 
(XEN) microcode: collect_cpu_info : sig=0x206a7, pf=0x2, rev=0x29
(XEN) microcode: collect_cpu_info : sig=0x206a7, pf=0x2, rev=0x29
(XEN) microcode: collect_cpu_info : sig=0x206a7, pf=0x2, rev=0x29


[-- Attachment #2: microcode-debug.patch --]
[-- Type: text/plain, Size: 1451 bytes --]

diff --git a/xen/arch/x86/microcode.c b/xen/arch/x86/microcode.c
index 091d5d1..48ff56b 100644
--- a/xen/arch/x86/microcode.c
+++ b/xen/arch/x86/microcode.c
@@ -21,6 +21,7 @@
  * 2 of the License, or (at your option) any later version.
  */
 
+#define DEBUG 1
 #include <xen/config.h>
 #include <xen/cpu.h>
 #include <xen/lib.h>
@@ -137,6 +138,7 @@ void __init microcode_scan_module(
         cd = find_cpio_data(p, _blob_start, _blob_size, &offset /* ignore */);
         if ( cd.data )
         {
+                printk("microcode payload @%d found (%ld)\n", i, cd.size);
                 /*
                  * This is an arbitrary check - it would be sad if the blob
                  * consumed most of the memory and did not allow guests
@@ -154,7 +156,8 @@ void __init microcode_scan_module(
                     cd.data = NULL;
                 else
                     memcpy(ucode_blob.data, cd.data, cd.size);
-        }
+        } else
+            printk("payload %d - nope\n", i);
         bootmap(NULL);
         if ( cd.data )
             break;
diff --git a/xen/arch/x86/microcode_intel.c b/xen/arch/x86/microcode_intel.c
index b54cd71..0445cca 100644
--- a/xen/arch/x86/microcode_intel.c
+++ b/xen/arch/x86/microcode_intel.c
@@ -33,7 +33,7 @@
 #include <asm/processor.h>
 #include <asm/microcode.h>
 
-#define pr_debug(x...) ((void)0)
+#define pr_debug(x...) printk(x)
 
 struct microcode_header_intel {
     unsigned int hdrver;

[-- Attachment #3: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

  reply	other threads:[~2014-03-12 13:50 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-06  5:21 How many patches are missing in upstream Linux? Zhang, Yang Z
2014-03-06 10:38 ` Jan Beulich
2014-03-06 13:47   ` Fabio Fantoni
2014-03-06 19:26   ` Konrad Rzeszutek Wilk
2014-03-06 19:36     ` David Vrabel
2014-03-06 19:39       ` Konrad Rzeszutek Wilk
2014-03-07  1:35         ` Zhang, Yang Z
2014-03-07  1:49     ` Zhang, Yang Z
2014-03-07  9:16     ` Jan Beulich
2014-03-10 20:55     ` Jeremy Fitzhardinge
2014-03-11 15:04       ` Konrad Rzeszutek Wilk
2014-03-11 16:15         ` Jan Beulich
2014-03-11 17:38           ` Konrad Rzeszutek Wilk
2014-03-11 17:38       ` Atom2
2014-03-11 17:53         ` Konrad Rzeszutek Wilk
2014-03-11 18:35           ` Atom2
2014-03-11 20:33             ` Konrad Rzeszutek Wilk
2014-03-12  1:00               ` Atom2
2014-03-12  8:20                 ` Jan Beulich
2014-03-12 11:14                   ` Atom2
2014-03-12 11:42                     ` Jan Beulich
2014-03-12 11:58                       ` Atom2
2014-03-12 13:50                         ` Konrad Rzeszutek Wilk [this message]
2014-03-12 15:09                           ` Atom2
2014-03-12 16:30                             ` Konrad Rzeszutek Wilk
2014-03-11 13:32     ` Ian Campbell
2014-03-11 15:09       ` Konrad Rzeszutek Wilk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140312135022.GC3245@phenom.dumpdata.com \
    --to=konrad.wilk@oracle.com \
    --cc=JBeulich@suse.com \
    --cc=ariel.atom2@web2web.at \
    --cc=boris.ostrovsky@oracle.com \
    --cc=daniel.kiper@oracle.com \
    --cc=david.vrabel@citrix.com \
    --cc=jeremy@goop.org \
    --cc=xen-devel@lists.xenproject.org \
    --cc=yang.z.zhang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.