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
next prev parent 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).