From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: How many patches are missing in upstream Linux? Date: Wed, 12 Mar 2014 09:50:22 -0400 Message-ID: <20140312135022.GC3245@phenom.dumpdata.com> References: <531E26DD.5030807@goop.org> <531F4A2C.7020209@web2web.at> <20140311175352.GC15088@phenom.dumpdata.com> <531F578B.40707@web2web.at> <20140311203329.GA7719@phenom.dumpdata.com> <531FB1AD.9080509@web2web.at> <532026ED0200007800123164@nat28.tlf.novell.com> <532041AB.3060905@web2web.at> <5320563102000078001232DE@nat28.tlf.novell.com> <53204BD5.6090602@web2web.at> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="dDRMvlgZJXvWKvBx" Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WNjYM-0004wc-En for xen-devel@lists.xenproject.org; Wed, 12 Mar 2014 13:50:38 +0000 Content-Disposition: inline In-Reply-To: <53204BD5.6090602@web2web.at> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Atom2 Cc: Jeremy Fitzhardinge , daniel.kiper@oracle.com, david.vrabel@citrix.com, Jan Beulich , Yang Z Zhang , "xen-devel@lists.xenproject.org" , boris.ostrovsky@oracle.com List-Id: xen-devel@lists.xenproject.org --dDRMvlgZJXvWKvBx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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 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 --dDRMvlgZJXvWKvBx Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="microcode-debug.patch" 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 #include #include @@ -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 #include -#define pr_debug(x...) ((void)0) +#define pr_debug(x...) printk(x) struct microcode_header_intel { unsigned int hdrver; --dDRMvlgZJXvWKvBx Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --dDRMvlgZJXvWKvBx--