xen-devel.lists.xenproject.org archive mirror
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).