From: Atom2 <ariel.atom2@web2web.at>
To: Jan Beulich <JBeulich@suse.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
daniel.kiper@oracle.com, david.vrabel@citrix.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 12:14:51 +0100 [thread overview]
Message-ID: <532041AB.3060905@web2web.at> (raw)
In-Reply-To: <532026ED0200007800123164@nat28.tlf.novell.com>
Am 12.03.14 09:20, schrieb Jan Beulich:
>>>> On 12.03.14 at 02:00, Atom2 <ariel.atom2@web2web.at> wrote:
>> Now to the bad news: The update of the microcode does not work if I use
>> ucode=scan - and that's regardless of whether I include just the small
>> 10k file for my CPU into the GenuineIntel.bin file or the complete
>> microcode for all Inter CPUs. The microcode of my CPU stays at 0x28
>> whereas with ucode=-1 and a separate binary microcode blob (in non-cpio
>> format) it gets updated to 0x29.
>>
>> I don't think that it is linked to CONFIG_MICROCODE_EARLY not being set
>> because as far as I understand linux would not be involved in the update
>> as this is done by xen. Or am I wrong here?
>
> And obviously without providing the log thereof (with "loglvl=all" in
> place) there's quite likely no way we can find out what's going
> wrong. If you have trouble setting up the serial console, yet the
> system is coming up fine (which it looks like it is), "xl dmesg" right
> after boot completed will do as good a job in obtaining the log.
Thats's a fair comment, but despite not having mentioned that (and I
appologize for not having been clear about that) I did look at xl dmesg
when the microcode update did not work and there were no error messages.
The relevant differences (compared with sdiff -s -l dmesg1 dmesg2 with
output split out seperately for the left side [dmesg1 - that's the one
with the separate payload "module'] and the right side [dmesg2 - that's
the one with the payload prepended to the initrd] due to width
constraints) are as follows:
dmesg1 - that's the one where the update works
(XEN) Command line: placeholder ucode=-1 vga=gfx-1024x768x32 i915.mod |
(XEN) Detected 2394.634 MHz processor. |
(XEN) microcode: CPU0 updated from revision 0x28 to 0x29, date = 2013 <
(XEN) microcode: CPU2 updated from revision 0x28 to 0x29, date = 2013 <
(XEN) microcode: CPU6 updated from revision 0x28 to 0x29, date = 2013 <
(XEN) microcode: CPU5 updated from revision 0x28 to 0x29, date = 2013 <
(XEN) Dom0 alloc.: 0000000800000000->0000000804000000 (1030164 pag |
(XEN) Init. ramdisk: 000000081de11000->000000081e5fcc00 |
(XEN) Init. ramdisk: ffffffff81e00000->ffffffff825ebc00 |
(XEN) Phys-Mach map: ffffffff825ec000->ffffffff82dec000 |
(XEN) Start info: ffffffff82dec000->ffffffff82dec4b4 |
(XEN) Page tables: ffffffff82ded000->ffffffff82e08000 |
(XEN) Boot stack: ffffffff82e08000->ffffffff82e09000 |
(XEN) TOTAL: ffffffff80000000->ffffffff83000000 |
dmesg2 - that's the one where the update doesn't work
| (XEN) Command line: placeholder ucode=scan vga=gfx-1024x768x32 i915.m
| (XEN) Detected 2394.643 MHz processor.
<
<
<
<
| (XEN) Dom0 alloc.: 0000000800000000->0000000804000000 (1031119 pag
| (XEN) Init. ramdisk: 000000081e1cf000->000000081e5ff580
| (XEN) Init. ramdisk: ffffffff81e00000->ffffffff82230580
| (XEN) Phys-Mach map: ffffffff82231000->ffffffff82a31000
| (XEN) Start info: ffffffff82a31000->ffffffff82a314b4
| (XEN) Page tables: ffffffff82a32000->ffffffff82a4b000
| (XEN) Boot stack: ffffffff82a4b000->ffffffff82a4c000
| (XEN) TOTAL: ffffffff80000000->ffffffff82c00000
So as you can see there's not much relevant difference other than the
missing messages relating to the microcode update in dmesg2.
Oh, and btw "loglvl=all guest_loglvl=all" was set in grub2 for both boot
sequences. For the second boot (dmesg2) the binary blob module line was
manually removed using grub2's 'e' command and at the same time the file
name in the remaining module line changed to point to the initrd with
the prepended microcode cpio archive. The change to the ucode parameter
is even visible in the output above.
And finally to also rule out that the changed initrd with the payload
prepended does not contain the microcode blob cpio, there's the output of
# cpio -itv < /boot/initrd-3.11.7-hardened-r1-ucode.gz
drwxr-xr-x 2 root root 0 Mar 12 01:28 kernel
drwxr-xr-x 2 root root 0 Mar 12 01:28 kernel/x86
drwxr-xr-x 2 root root 0 Mar 12 01:28 kernel/x86/microcode
-rw-r--r-- 1 root root 600064 Mar 12 01:28
kernel/x86/microcode/GenuineIntel.bin
If there's anything else, just tell me what you require.
Thanks Atom2
next prev parent reply other threads:[~2014-03-12 11:15 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 [this message]
2014-03-12 11:42 ` Jan Beulich
2014-03-12 11:58 ` Atom2
2014-03-12 13:50 ` Konrad Rzeszutek Wilk
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=532041AB.3060905@web2web.at \
--to=ariel.atom2@web2web.at \
--cc=JBeulich@suse.com \
--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).