How many patches are missing in upstream Linux?

How many patches are missing in upstream Linux?

[Zhang, Yang Z]

Hi Konrad,

Do you know how many features or patches are still missing in upstream Linux? I know some of them, like hugepage support, TS bit issue and PAT issue. But I guess I only known part of them. Is there any wiki page to track that information?

best regards
yang

Re: How many patches are missing in upstream Linux?

[Jan Beulich]

>>> On 06.03.14 at 06:21, "Zhang, Yang Z" <yang.z.zhang@intel.com> wrote:
> Do you know how many features or patches are still missing in upstream 
> Linux? I know some of them, like hugepage support, TS bit issue and PAT 
> issue. But I guess I only known part of them. Is there any wiki page to track 
> that information?

A few more that I know of:

- EFI
- user mode accessible PV clock
- runtime microcode loading
- support for running with more than 1Tb (XEN_ELFNOTE_INIT_P2M)
  (but afaict there are also shortcomings needing fixing in the tools
  when going beyond 512Gb)
- support for using huge initrd (XEN_ELFNOTE_MOD_START_PFN)
- blktap (or a suitable replacement thereof)
- pvSCSI
- pvUSB
- perf/oprof

Plus various smaller items where e.g. certain special drivers need
adjustments to work right in dom0 (dcdbas, dell_rbu, coretemp,
via-cputemp, msr).

Also I'm not certain whether the MSI-X issue that was found a while
ago is meanwhile fully fixed.

Jan

Re: How many patches are missing in upstream Linux?

[Fabio Fantoni]

Il 06/03/2014 11:38, Jan Beulich ha scritto:
>>>> On 06.03.14 at 06:21, "Zhang, Yang Z" <yang.z.zhang@intel.com> wrote:
>> Do you know how many features or patches are still missing in upstream
>> Linux? I know some of them, like hugepage support, TS bit issue and PAT
>> issue. But I guess I only known part of them. Is there any wiki page to track
>> that information?
> A few more that I know of:
>
> - EFI
> - user mode accessible PV clock
> - runtime microcode loading
> - support for running with more than 1Tb (XEN_ELFNOTE_INIT_P2M)
>    (but afaict there are also shortcomings needing fixing in the tools
>    when going beyond 512Gb)
> - support for using huge initrd (XEN_ELFNOTE_MOD_START_PFN)
> - blktap (or a suitable replacement thereof)
> - pvSCSI
> - pvUSB
> - perf/oprof
>
> Plus various smaller items where e.g. certain special drivers need
> adjustments to work right in dom0 (dcdbas, dell_rbu, coretemp,
> via-cputemp, msr).
>
> Also I'm not certain whether the MSI-X issue that was found a while
> ago is meanwhile fully fixed.

One msi problem is still present and I have not found a solution, last 
mail with details is here:
http://lists.xen.org/archives/html/xen-devel/2014-02/msg00192.html
Can somebody help me about it please?

Thanks for any reply.

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

Re: How many patches are missing in upstream Linux?

[Konrad Rzeszutek Wilk]

On Thu, Mar 06, 2014 at 10:38:53AM +0000, Jan Beulich wrote:
> >>> On 06.03.14 at 06:21, "Zhang, Yang Z" <yang.z.zhang@intel.com> wrote:
> > Do you know how many features or patches are still missing in upstream 
> > Linux? I know some of them, like hugepage support, TS bit issue and PAT 
> > issue. But I guess I only known part of them. Is there any wiki page to track 

It might make sense to split this in five categories: Being worked on,
PVH can fulfill that, Hadn't looked at, and 'Simple enough - but it
would fantanstic if somebody could spare some time to look at it', the
maintainer is being <insert your own opinion here>..

If anybody is interested in helping, this list should give a good idea.
It would be quite helpful to have more folks look at some of these.

Being worked on are:
 - EFI (Daniel Kiper, CC-ed)
 - perf (Boris Ostrovsky, CC-ed).
 - user mode accessible PV clock (Boris or me)
 - XEN_ELFNOTE_INIT_P2M, XEN_ELFNOTE_MOD_START_PFN - I had been looking
   at that but I can't figure out a nice way of implementing this
   without the usage of SPARSEMAP_VMAP virtual addresses - which is how
   the classic Xen does it. But then - I don't know who is using huge PV
   guests - as the PVHVM does a fine job? But then with PVH, now you can
   boot with large amount of memory (1TB?) - so some of these issues
   would go away? Except the 'large ramdisk' as that would eat in the
   MODULES_VADDR I think? Needs more thinking.


PVH can do it:
 - PAT (it works right out of the box).
 - hugepages support (1Gb, 2MB, etc - all works!)
 - TS bit issue (works too).

Simple enough - but it would fantastic if somebody could spare some
time:
 - PAT - hpa suggested a nice way of making this work. It involes a sort
   of software lookup of WC, WP, UC bits. The complexity comes when it
   you have to deal with it on 4th and 3rd level pagetables and which
   bit to flip. But now that I think of, it should be as easy as having:

    pte_t get_bit_for_wc(int level)
   or such. That would allow PV guests to run this.

- TS bit issue. David Vrabel was mulling this one over. (CC-ed).

Hadn't looked at:
 - pvSCSI,
 - pvUSB
 - blktap (My recolleciton is that Citrix is just carrying the old
   patchset around - but the end goal would be for QEMU to do all
   of this - but they haven't found somebody willing to do a lot
   of the work in this).

Hadn't heard of before:
 - dcdbas
 - rbu
 - coretemp,
  -via-cputemp
Sounds like those driver just need a bit of fixes then? Perhaps their
issues have now been resolved with the 1-1 mapping and the latest set of
patches that David Vrabel had posted? Which makes the P2M code much more
smarter?

The maintainer is being <insert your own opinion here>:
 - runtime microcode. What I had been told was to use the 'early
   microcode' mechanism - which is now implemented and Xen can also scan
   the initramfs to extract the microcode payload and apply it.

   But it misses the important part of server longevity in that the
   host might be running for years and the microcode might need to be
   updated during that time. bpetkov wasn't too thrilled about the
   runtime microcode and I hadn't come back to this yet to figure out
   what are his exact technical misgivings.



MSI-X -  I presume you are referring to
http://comments.gmane.org/gmane.comp.emulators.xen.devel/170534

That had been taking me through so many twists and turns. The only
machine I had which manifested this was an Intel SandyBridge Desktop. But of
course the BIOS does not do SR-IOV. But no worry - I implemented the
'assign-busses' mechanism to do what the BIOS couldn't do (expand the
bus numbers). Great, now I do finally see the issue. And the patch
I had posted for Linux (which is in Linux 3.14) solves the problem
part-way. I had been mulling this a bit but don't have yet a good
solution.

So many things, so little time. Zhang are you able to help with some of
these?
> > that information?
> 
> A few more that I know of:
> 
> - EFI
> - user mode accessible PV clock
> - runtime microcode loading
> - support for running with more than 1Tb (XEN_ELFNOTE_INIT_P2M)
>   (but afaict there are also shortcomings needing fixing in the tools
>   when going beyond 512Gb)
> - support for using huge initrd (XEN_ELFNOTE_MOD_START_PFN)
> - blktap (or a suitable replacement thereof)
> - pvSCSI
> - pvUSB
> - perf/oprof
> 
> Plus various smaller items where e.g. certain special drivers need
> adjustments to work right in dom0 (dcdbas, dell_rbu, coretemp,
> via-cputemp, msr).
> 
> Also I'm not certain whether the MSI-X issue that was found a while
> ago is meanwhile fully fixed.
> 
> Jan
> 

Re: How many patches are missing in upstream Linux?

[David Vrabel]

On 06/03/2014 19:26, Konrad Rzeszutek Wilk wrote:
> 
> - TS bit issue. David Vrabel was mulling this one over. (CC-ed).

Er. Am I?  I'm not sure what this refers to.

David

Re: How many patches are missing in upstream Linux?

[Konrad Rzeszutek Wilk]

On Thu, Mar 06, 2014 at 07:36:55PM +0000, David Vrabel wrote:
> On 06/03/2014 19:26, Konrad Rzeszutek Wilk wrote:
> > 
> > - TS bit issue. David Vrabel was mulling this one over. (CC-ed).
> 
> Er. Am I?  I'm not sure what this refers to.

I thought so?

This is http://bugs.xenproject.org/xen/bug/40 and I thought you mentioned some
form of mempool for the allocation of the FPU so that we won't allocate
during task switches? But you weren't too thrilled about it?

> 
> David
> 

Re: How many patches are missing in upstream Linux?

[Zhang, Yang Z]

Konrad Rzeszutek Wilk wrote on 2014-03-07:
> On Thu, Mar 06, 2014 at 07:36:55PM +0000, David Vrabel wrote:
>> On 06/03/2014 19:26, Konrad Rzeszutek Wilk wrote:
>>> 
>>> - TS bit issue. David Vrabel was mulling this one over. (CC-ed).
>> 
>> Er. Am I?  I'm not sure what this refers to.
> 
> I thought so?
> 
> This is http://bugs.xenproject.org/xen/bug/40 and I thought you

Yes, it's the issue. 

> mentioned some form of mempool for the allocation of the FPU so that
> we won't allocate during task switches? But you weren't too thrilled about it?
> 
>> 
>> David
>>


Best regards,
Yang

Re: How many patches are missing in upstream Linux?

[Zhang, Yang Z]

Konrad Rzeszutek Wilk wrote on 2014-03-07:
> On Thu, Mar 06, 2014 at 10:38:53AM +0000, Jan Beulich wrote:
>>>>> On 06.03.14 at 06:21, "Zhang, Yang Z" <yang.z.zhang@intel.com>
> wrote:
>>> Do you know how many features or patches are still missing in
>>> upstream Linux? I know some of them, like hugepage support, TS bit
>>> issue and PAT issue. But I guess I only known part of them. Is
>>> there any wiki page to track
> 
> It might make sense to split this in five categories: Being worked on,
> PVH can fulfill that, Hadn't looked at, and 'Simple enough - but it
> would fantanstic if somebody could spare some time to look at it', the
> maintainer is being <insert your own opinion here>..
> 
> If anybody is interested in helping, this list should give a good idea.
> It would be quite helpful to have more folks look at some of these.
> 
> Being worked on are:
>  - EFI (Daniel Kiper, CC-ed)
>  - perf (Boris Ostrovsky, CC-ed).
>  - user mode accessible PV clock (Boris or me)
>  - XEN_ELFNOTE_INIT_P2M, XEN_ELFNOTE_MOD_START_PFN - I had been
> looking
>    at that but I can't figure out a nice way of implementing this
>    without the usage of SPARSEMAP_VMAP virtual addresses - which is how
>    the classic Xen does it. But then - I don't know who is using huge PV
>    guests - as the PVHVM does a fine job? But then with PVH, now you can
>    boot with large amount of memory (1TB?) - so some of these issues
>    would go away? Except the 'large ramdisk' as that would eat in the
>    MODULES_VADDR I think? Needs more thinking.
> 
> PVH can do it:
>  - PAT (it works right out of the box).
>  - hugepages support (1Gb, 2MB, etc - all works!)
>  - TS bit issue (works too).
> Simple enough - but it would fantastic if somebody could spare some
> time:
>  - PAT - hpa suggested a nice way of making this work. It involes a sort
>    of software lookup of WC, WP, UC bits. The complexity comes when it
>    you have to deal with it on 4th and 3rd level pagetables and which
>    bit to flip. But now that I think of, it should be as easy as having:
>     pte_t get_bit_for_wc(int level)
>    or such. That would allow PV guests to run this.
> - TS bit issue. David Vrabel was mulling this one over. (CC-ed).
> 
> Hadn't looked at:
>  - pvSCSI,
>  - pvUSB
>  - blktap (My recolleciton is that Citrix is just carrying the old
>    patchset around - but the end goal would be for QEMU to do all
>    of this - but they haven't found somebody willing to do a lot
>    of the work in this).
> Hadn't heard of before:
>  - dcdbas
>  - rbu
>  - coretemp,
>   -via-cputemp
> Sounds like those driver just need a bit of fixes then? Perhaps their
> issues have now been resolved with the 1-1 mapping and the latest set
> of patches that David Vrabel had posted? Which makes the P2M code much more smarter?
> 
> The maintainer is being <insert your own opinion here>:
>  - runtime microcode. What I had been told was to use the 'early
>    microcode' mechanism - which is now implemented and Xen can also scan
>    the initramfs to extract the microcode payload and apply it.
>    
>    But it misses the important part of server longevity in that the
>    host might be running for years and the microcode might need to be
>    updated during that time. bpetkov wasn't too thrilled about the
>    runtime microcode and I hadn't come back to this yet to figure out
>    what are his exact technical misgivings.
> 
> 
> MSI-X -  I presume you are referring to
> http://comments.gmane.org/gmane.comp.emulators.xen.devel/170534
> 
> That had been taking me through so many twists and turns. The only
> machine I had which manifested this was an Intel SandyBridge Desktop.
> But of course the BIOS does not do SR-IOV. But no worry - I implemented the 'assign-busses'
> mechanism to do what the BIOS couldn't do (expand the bus numbers).
> Great, now I do finally see the issue. And the patch I had posted for
> Linux (which is in Linux 3.14) solves the problem part-way. I had been
> mulling this a bit but don't have yet a good solution.

Thanks for providing the information.
I think it's better to list them on wiki for people to check. Because I have been asked by customers to solve the problem often and the root-cause turns out to be the issue we already known but customer didn't aware of them. Especially for TS issue, I saw it from three different customers. The customers usually use the stable Linux as dom0 directly without any additional patch and they even don't know there are known issues for upstream Linux(There is no way for them to get it). So if we can put it in wiki, I think it will help them a lot.

> 
> So many things, so little time. Zhang are you able to help with some of these?

I hope I can. But there also lots of task waiting for me. :(

>>> that information?
>> 
>> A few more that I know of:
>> 
>> - EFI
>> - user mode accessible PV clock
>> - runtime microcode loading
>> - support for running with more than 1Tb (XEN_ELFNOTE_INIT_P2M)
>>   (but afaict there are also shortcomings needing fixing in the tools
>>   when going beyond 512Gb)
>> - support for using huge initrd (XEN_ELFNOTE_MOD_START_PFN)
>> - blktap (or a suitable replacement thereof)
>> - pvSCSI
>> - pvUSB
>> - perf/oprof
>> 
>> Plus various smaller items where e.g. certain special drivers need
>> adjustments to work right in dom0 (dcdbas, dell_rbu, coretemp,
>> via-cputemp, msr).
>> 
>> Also I'm not certain whether the MSI-X issue that was found a while
>> ago is meanwhile fully fixed.
>> 
>> Jan
>>


Best regards,
Yang

Re: How many patches are missing in upstream Linux?

[Jan Beulich]

>>> On 06.03.14 at 20:26, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> PVH can do it:
>  - PAT (it works right out of the box).
>  - hugepages support (1Gb, 2MB, etc - all works!)
>  - TS bit issue (works too).

Which very much depends on how long it'll take to get PVH out of
technical preview state. Considering how long it to it to get where
we're now, this may be a while...

Jan

Re: How many patches are missing in upstream Linux?

[Jeremy Fitzhardinge]

On 03/06/2014 11:26 AM, Konrad Rzeszutek Wilk wrote:
> Being worked on are:
>  - EFI (Daniel Kiper, CC-ed)

This has been a blocker for me. My new laptop is EFI booting, so I
haven't been running Xen on it for the last few months. I don't have
much time for deep work on it, but I'm happy to be a test subject.

>  - perf (Boris Ostrovsky, CC-ed).
>  - user mode accessible PV clock (Boris or me)
I did have some work on this, but I don't remember how far it got. I
think it stumbled on having a mechanism to allow usermode to detect it
had switched physical cpus. Is this a continuation of my patches or a
new attempt?

> The maintainer is being <insert your own opinion here>:
>  - runtime microcode. What I had been told was to use the 'early
>    microcode' mechanism - which is now implemented and Xen can also scan
>    the initramfs to extract the microcode payload and apply it.

I've never got that to work, but ucode=-1 with a microcode.dat multiboot
modules works pretty well.

>    But it misses the important part of server longevity in that the
>    host might be running for years and the microcode might need to be
>    updated during that time. bpetkov wasn't too thrilled about the
>    runtime microcode and I hadn't come back to this yet to figure out
>    what are his exact technical misgivings.

I think, in the end, he (and Ingo) were advocating just doing a full
emulation of the Intel/AMD update mechanism in the set/getmsr PV
callbacks. Which is doable but... well, not pretty. Maybe a new attempt
with get a new reception.

    J

>
>
>
> MSI-X -  I presume you are referring to
> http://comments.gmane.org/gmane.comp.emulators.xen.devel/170534
>
> That had been taking me through so many twists and turns. The only
> machine I had which manifested this was an Intel SandyBridge Desktop. But of
> course the BIOS does not do SR-IOV. But no worry - I implemented the
> 'assign-busses' mechanism to do what the BIOS couldn't do (expand the
> bus numbers). Great, now I do finally see the issue. And the patch
> I had posted for Linux (which is in Linux 3.14) solves the problem
> part-way. I had been mulling this a bit but don't have yet a good
> solution.
>
> So many things, so little time. Zhang are you able to help with some of
> these?
>>> that information?
>> A few more that I know of:
>>
>> - EFI
>> - user mode accessible PV clock
>> - runtime microcode loading
>> - support for running with more than 1Tb (XEN_ELFNOTE_INIT_P2M)
>>   (but afaict there are also shortcomings needing fixing in the tools
>>   when going beyond 512Gb)
>> - support for using huge initrd (XEN_ELFNOTE_MOD_START_PFN)
>> - blktap (or a suitable replacement thereof)
>> - pvSCSI
>> - pvUSB
>> - perf/oprof
>>
>> Plus various smaller items where e.g. certain special drivers need
>> adjustments to work right in dom0 (dcdbas, dell_rbu, coretemp,
>> via-cputemp, msr).
>>
>> Also I'm not certain whether the MSI-X issue that was found a while
>> ago is meanwhile fully fixed.
>>
>> Jan
>>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>

Re: How many patches are missing in upstream Linux?

[Ian Campbell]

On Thu, 2014-03-06 at 14:26 -0500, Konrad Rzeszutek Wilk wrote:
> Hadn't looked at:
>  - pvSCSI,
>  - pvUSB
>  - blktap (My recolleciton is that Citrix is just carrying the old
>    patchset around - but the end goal would be for QEMU to do all
>    of this - but they haven't found somebody willing to do a lot
>    of the work in this).

I think Qemu is already a pretty good fit, modulo some vague belief that
blktap's vhd handling might be in some way superior. xl mostly just uses
qemu when blkback isn't appropriate these days.

> The maintainer is being <insert your own opinion here>:
>  - runtime microcode. What I had been told was to use the 'early
>    microcode' mechanism - which is now implemented and Xen can also scan
>    the initramfs to extract the microcode payload and apply it.
> 
>    But it misses the important part of server longevity in that the
>    host might be running for years and the microcode might need to be
>    updated during that time. bpetkov wasn't too thrilled about the
>    runtime microcode and I hadn't come back to this yet to figure out
>    what are his exact technical misgivings.

I have a vague memory of a userspace tool for calling the microcode
hypercalls directly, which might suck from the point of view of needing
to re-integrate with the distros existing use of the regular tools, but
is better than nothing I guess.

Am I totally imagining that tool?

Ian.

Re: How many patches are missing in upstream Linux?

[Konrad Rzeszutek Wilk]

On Mon, Mar 10, 2014 at 01:55:57PM -0700, Jeremy Fitzhardinge wrote:
> 
> On 03/06/2014 11:26 AM, Konrad Rzeszutek Wilk wrote:
> > Being worked on are:
> >  - EFI (Daniel Kiper, CC-ed)
> 
> This has been a blocker for me. My new laptop is EFI booting, so I
> haven't been running Xen on it for the last few months. I don't have
> much time for deep work on it, but I'm happy to be a test subject.
> 
> >  - perf (Boris Ostrovsky, CC-ed).
> >  - user mode accessible PV clock (Boris or me)
> I did have some work on this, but I don't remember how far it got. I
> think it stumbled on having a mechanism to allow usermode to detect it
> had switched physical cpus. Is this a continuation of my patches or a
> new attempt?
> 
> > The maintainer is being <insert your own opinion here>:
> >  - runtime microcode. What I had been told was to use the 'early
> >    microcode' mechanism - which is now implemented and Xen can also scan
> >    the initramfs to extract the microcode payload and apply it.
> 
> I've never got that to work, but ucode=-1 with a microcode.dat multiboot
> modules works pretty well.

Odd. It should be fairly easy with the newest version of dracut. Just
add this in your /etc/dracut.conf

early_microcode="yes"

and obviously in your grub.cfg (/etc/default/grub) add on the Xen command line
GRUB_CMDLINE_XEN="scan=ucode"

> 
> >    But it misses the important part of server longevity in that the
> >    host might be running for years and the microcode might need to be
> >    updated during that time. bpetkov wasn't too thrilled about the
> >    runtime microcode and I hadn't come back to this yet to figure out
> >    what are his exact technical misgivings.
> 
> I think, in the end, he (and Ingo) were advocating just doing a full
> emulation of the Intel/AMD update mechanism in the set/getmsr PV
> callbacks. Which is doable but... well, not pretty. Maybe a new attempt
> with get a new reception.

I did look at that. And realized to make that work I would have to implement
the full parsing of microcode that the existing microcode code does.

Fortunatly the hypervisor does that already - so it would be possible for 
Xen to intercept the MSRs and just store the payload in some structure - and
when completed then run the microcode verify to see if it matches.

But it was not clear to me how to figure out whether we are done with
the 'upload' unless I do some early parsing of the microcode to figure
out the length. Which then means adding extra plumbing in the microcode API
in Xen.

> 
>     J
> 
> >
> >
> >
> > MSI-X -  I presume you are referring to
> > http://comments.gmane.org/gmane.comp.emulators.xen.devel/170534
> >
> > That had been taking me through so many twists and turns. The only
> > machine I had which manifested this was an Intel SandyBridge Desktop. But of
> > course the BIOS does not do SR-IOV. But no worry - I implemented the
> > 'assign-busses' mechanism to do what the BIOS couldn't do (expand the
> > bus numbers). Great, now I do finally see the issue. And the patch
> > I had posted for Linux (which is in Linux 3.14) solves the problem
> > part-way. I had been mulling this a bit but don't have yet a good
> > solution.
> >
> > So many things, so little time. Zhang are you able to help with some of
> > these?
> >>> that information?
> >> A few more that I know of:
> >>
> >> - EFI
> >> - user mode accessible PV clock
> >> - runtime microcode loading
> >> - support for running with more than 1Tb (XEN_ELFNOTE_INIT_P2M)
> >>   (but afaict there are also shortcomings needing fixing in the tools
> >>   when going beyond 512Gb)
> >> - support for using huge initrd (XEN_ELFNOTE_MOD_START_PFN)
> >> - blktap (or a suitable replacement thereof)
> >> - pvSCSI
> >> - pvUSB
> >> - perf/oprof
> >>
> >> Plus various smaller items where e.g. certain special drivers need
> >> adjustments to work right in dom0 (dcdbas, dell_rbu, coretemp,
> >> via-cputemp, msr).
> >>
> >> Also I'm not certain whether the MSI-X issue that was found a while
> >> ago is meanwhile fully fixed.
> >>
> >> Jan
> >>
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> >
> 

Re: How many patches are missing in upstream Linux?

[Konrad Rzeszutek Wilk]

On Tue, Mar 11, 2014 at 01:32:11PM +0000, Ian Campbell wrote:
> On Thu, 2014-03-06 at 14:26 -0500, Konrad Rzeszutek Wilk wrote:
> > Hadn't looked at:
> >  - pvSCSI,
> >  - pvUSB
> >  - blktap (My recolleciton is that Citrix is just carrying the old
> >    patchset around - but the end goal would be for QEMU to do all
> >    of this - but they haven't found somebody willing to do a lot
> >    of the work in this).
> 
> I think Qemu is already a pretty good fit, modulo some vague belief that
> blktap's vhd handling might be in some way superior. xl mostly just uses
> qemu when blkback isn't appropriate these days.
> 
> > The maintainer is being <insert your own opinion here>:
> >  - runtime microcode. What I had been told was to use the 'early
> >    microcode' mechanism - which is now implemented and Xen can also scan
> >    the initramfs to extract the microcode payload and apply it.
> > 
> >    But it misses the important part of server longevity in that the
> >    host might be running for years and the microcode might need to be
> >    updated during that time. bpetkov wasn't too thrilled about the
> >    runtime microcode and I hadn't come back to this yet to figure out
> >    what are his exact technical misgivings.
> 
> I have a vague memory of a userspace tool for calling the microcode
> hypercalls directly, which might suck from the point of view of needing
> to re-integrate with the distros existing use of the regular tools, but
> is better than nothing I guess.
> 
> Am I totally imagining that tool?

I did wrote it as a test to see if it could be done that way. And sure enough
it worked (I can't find it now, but I am sure Google can help).
But there are two insertions points in Linux for microcode:

1). You do a 'scan' or something like that in /sysfs. And it plucks the
   firmware images from /lib/firmware/[amd|intel]_ucode/*

2). You cat the blob in /dev/cpuX/<Something> and the kernel tries to apply
    it.


All of that is kind of driven by scripts - so my thought was too look at what
the distro scripts do for this. Or whether this is all suppose to be
automatic (udev sees a CPU, pokes at the /sysfs' and the microcode is updated).
But then there are many distros and..

Or just ignore all of that and implement it in the hypervisor and not worry
about it. But that is not nice and I think Jan would not be too happy
with me savaging the microcode API.

And I think I choose to implement the 'early-microcode' as a way to have this
working now.
> 
> Ian.
> 

Re: How many patches are missing in upstream Linux?

[Jan Beulich]

>>> On 11.03.14 at 16:04, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> On Mon, Mar 10, 2014 at 01:55:57PM -0700, Jeremy Fitzhardinge wrote:
>> 
>> On 03/06/2014 11:26 AM, Konrad Rzeszutek Wilk wrote:
>> > Being worked on are:
>> >  - EFI (Daniel Kiper, CC-ed)
>> 
>> This has been a blocker for me. My new laptop is EFI booting, so I
>> haven't been running Xen on it for the last few months. I don't have
>> much time for deep work on it, but I'm happy to be a test subject.
>> 
>> >  - perf (Boris Ostrovsky, CC-ed).
>> >  - user mode accessible PV clock (Boris or me)
>> I did have some work on this, but I don't remember how far it got. I
>> think it stumbled on having a mechanism to allow usermode to detect it
>> had switched physical cpus. Is this a continuation of my patches or a
>> new attempt?
>> 
>> > The maintainer is being <insert your own opinion here>:
>> >  - runtime microcode. What I had been told was to use the 'early
>> >    microcode' mechanism - which is now implemented and Xen can also scan
>> >    the initramfs to extract the microcode payload and apply it.
>> 
>> I've never got that to work, but ucode=-1 with a microcode.dat multiboot
>> modules works pretty well.
> 
> Odd. It should be fairly easy with the newest version of dracut. Just
> add this in your /etc/dracut.conf
> 
> early_microcode="yes"
> 
> and obviously in your grub.cfg (/etc/default/grub) add on the Xen command 
> line
> GRUB_CMDLINE_XEN="scan=ucode"

The other way around I think: "ucode=scan".

Jan

Re: How many patches are missing in upstream Linux?

[Konrad Rzeszutek Wilk]

On Tue, Mar 11, 2014 at 04:15:38PM +0000, Jan Beulich wrote:
> >>> On 11.03.14 at 16:04, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > On Mon, Mar 10, 2014 at 01:55:57PM -0700, Jeremy Fitzhardinge wrote:
> >> 
> >> On 03/06/2014 11:26 AM, Konrad Rzeszutek Wilk wrote:
> >> > Being worked on are:
> >> >  - EFI (Daniel Kiper, CC-ed)
> >> 
> >> This has been a blocker for me. My new laptop is EFI booting, so I
> >> haven't been running Xen on it for the last few months. I don't have
> >> much time for deep work on it, but I'm happy to be a test subject.
> >> 
> >> >  - perf (Boris Ostrovsky, CC-ed).
> >> >  - user mode accessible PV clock (Boris or me)
> >> I did have some work on this, but I don't remember how far it got. I
> >> think it stumbled on having a mechanism to allow usermode to detect it
> >> had switched physical cpus. Is this a continuation of my patches or a
> >> new attempt?
> >> 
> >> > The maintainer is being <insert your own opinion here>:
> >> >  - runtime microcode. What I had been told was to use the 'early
> >> >    microcode' mechanism - which is now implemented and Xen can also scan
> >> >    the initramfs to extract the microcode payload and apply it.
> >> 
> >> I've never got that to work, but ucode=-1 with a microcode.dat multiboot
> >> modules works pretty well.
> > 
> > Odd. It should be fairly easy with the newest version of dracut. Just
> > add this in your /etc/dracut.conf
> > 
> > early_microcode="yes"
> > 
> > and obviously in your grub.cfg (/etc/default/grub) add on the Xen command 
> > line
> > GRUB_CMDLINE_XEN="scan=ucode"
> 
> The other way around I think: "ucode=scan".

Right! Thanks for spotting that.
> 
> Jan
> 

Re: How many patches are missing in upstream Linux?

[Atom2]

Am 10.03.14 21:55, schrieb Jeremy Fitzhardinge:
[snip]
>> The maintainer is being <insert your own opinion here>:
>>   - runtime microcode. What I had been told was to use the 'early
>>     microcode' mechanism - which is now implemented and Xen can also scan
>>     the initramfs to extract the microcode payload and apply it.
>
> I've never got that to work, but ucode=-1 with a microcode.dat multiboot
> modules works pretty well.
>
>>     But it misses the important part of server longevity in that the
>>     host might be running for years and the microcode might need to be
>>     updated during that time. bpetkov wasn't too thrilled about the
>>     runtime microcode and I hadn't come back to this yet to figure out
>>     what are his exact technical misgivings.
>
> I think, in the end, he (and Ingo) were advocating just doing a full
> emulation of the Intel/AMD update mechanism in the set/getmsr PV
> callbacks. Which is doable but... well, not pretty. Maybe a new attempt
> with get a new reception.

I can add my experience from the perspective of a user trying to get 
early microcode loading to work with my system:

First of all I can confirm that it sort of works - but as Jeremy has 
pointed out, there seem to be issues with including it into the 
initramfs. After many unsuccessful tries I also only got it to work when 
I used a separate entry in multiboot (grub2) which referred to the blob 
for uploading the payload to the CPU.

As soon as I had the microcode integrated into the initramfs as 
described at 
http://lists.xen.org/archives/html/xen-devel/2013-09/msg02902.html the 
system would no longer boot with a message stating that it could not 
find the root filesystem - I assume that was at the time when the 
initramfs was about to be unpacked and loaded (if I recall correctly 
there were no messages from the initramfs on screen). Therefore I 
couldn't verify whether the microcode was actually lodaded before that.

My feeling at that time was that the unpacking of the initramfs had 
failed and it was probably more a linux issue rather than a XEN issue - 
albeit the concatenated file which per the link above should be created by

"cat ucode.cpio /boot/initrd-3.5.0.img >/boot/initrd-3.5.0.ucode.img"

does not resemble a valid cpio archive any longer (you also can't work 
with it on the command line - e.g. list its content). I assume that 
though the kernel expects a valid cpio format file and therefore is 
unable to unpack and subsequently fails.

But in any case, with the additional file in multiboot it works 
flawlessly. The only catch is that the file distributed by Intel (the 
microcode.dat which is a text file) has to be converted inot a binary 
file (I also stripped it down to only contain the parts necessary for my 
CPU, but I don't know whether that's strictly necessary). And it must 
_NOT_ be a cpio archive in that case.

Searching google there are a few tools available to convert the Intel 
distributed microcode.dat to binary format and reduce it to only the 
parts required for a specific CPU.

Regards Atom2

Re: How many patches are missing in upstream Linux?

[Konrad Rzeszutek Wilk]

On Tue, Mar 11, 2014 at 06:38:52PM +0100, Atom2 wrote:
> 
> 
> Am 10.03.14 21:55, schrieb Jeremy Fitzhardinge:
> [snip]
> >>The maintainer is being <insert your own opinion here>:
> >>  - runtime microcode. What I had been told was to use the 'early
> >>    microcode' mechanism - which is now implemented and Xen can also scan
> >>    the initramfs to extract the microcode payload and apply it.
> >
> >I've never got that to work, but ucode=-1 with a microcode.dat multiboot
> >modules works pretty well.
> >
> >>    But it misses the important part of server longevity in that the
> >>    host might be running for years and the microcode might need to be
> >>    updated during that time. bpetkov wasn't too thrilled about the
> >>    runtime microcode and I hadn't come back to this yet to figure out
> >>    what are his exact technical misgivings.
> >
> >I think, in the end, he (and Ingo) were advocating just doing a full
> >emulation of the Intel/AMD update mechanism in the set/getmsr PV
> >callbacks. Which is doable but... well, not pretty. Maybe a new attempt
> >with get a new reception.
> 
> I can add my experience from the perspective of a user trying to get
> early microcode loading to work with my system:
> 
> First of all I can confirm that it sort of works - but as Jeremy has
> pointed out, there seem to be issues with including it into the
> initramfs. After many unsuccessful tries I also only got it to work
> when I used a separate entry in multiboot (grub2) which referred to
> the blob for uploading the payload to the CPU.
> 
> As soon as I had the microcode integrated into the initramfs as
> described at
> http://lists.xen.org/archives/html/xen-devel/2013-09/msg02902.html
> the system would no longer boot with a message stating that it could
> not find the root filesystem - I assume that was at the time when
> the initramfs was about to be unpacked and loaded (if I recall
> correctly there were no messages from the initramfs on screen).
> Therefore I couldn't verify whether the microcode was actually
> lodaded before that.

Hm, that would imply that Linux couldn't skip past the 'non-gzip'
payload of the initramfs. But it does work for me so I am wondering
what I am doing differently.

Could you send an email with your .config and perhaps your serial log
if you still have it?


> 
> My feeling at that time was that the unpacking of the initramfs had
> failed and it was probably more a linux issue rather than a XEN
> issue - albeit the concatenated file which per the link above should
> be created by
> 
> "cat ucode.cpio /boot/initrd-3.5.0.img >/boot/initrd-3.5.0.ucode.img"
> 
> does not resemble a valid cpio archive any longer (you also can't
> work with it on the command line - e.g. list its content). I assume
> that though the kernel expects a valid cpio format file and
> therefore is unable to unpack and subsequently fails.

It should skip the bits that it does not understand.
> 
> But in any case, with the additional file in multiboot it works
> flawlessly. The only catch is that the file distributed by Intel
> (the microcode.dat which is a text file) has to be converted inot a
> binary file (I also stripped it down to only contain the parts
> necessary for my CPU, but I don't know whether that's strictly
> necessary). And it must _NOT_ be a cpio archive in that case.

You should be able to do 'cat /lib/firmware/intel_ucode/* > /boot/microcode.blob'
and that would do it too.

> 
> Searching google there are a few tools available to convert the
> Intel distributed microcode.dat to binary format and reduce it to
> only the parts required for a specific CPU.
> 
> Regards Atom2

Re: How many patches are missing in upstream Linux?

[Atom2]

Am 11.03.14 18:53, schrieb Konrad Rzeszutek Wilk:
> On Tue, Mar 11, 2014 at 06:38:52PM +0100, Atom2 wrote:
>>
>>
>> Am 10.03.14 21:55, schrieb Jeremy Fitzhardinge:
>> [snip]
>>>> The maintainer is being <insert your own opinion here>:
>>>>   - runtime microcode. What I had been told was to use the 'early
>>>>     microcode' mechanism - which is now implemented and Xen can also scan
>>>>     the initramfs to extract the microcode payload and apply it.
>>>
>>> I've never got that to work, but ucode=-1 with a microcode.dat multiboot
>>> modules works pretty well.
>>>
>>>>     But it misses the important part of server longevity in that the
>>>>     host might be running for years and the microcode might need to be
>>>>     updated during that time. bpetkov wasn't too thrilled about the
>>>>     runtime microcode and I hadn't come back to this yet to figure out
>>>>     what are his exact technical misgivings.
>>>
>>> I think, in the end, he (and Ingo) were advocating just doing a full
>>> emulation of the Intel/AMD update mechanism in the set/getmsr PV
>>> callbacks. Which is doable but... well, not pretty. Maybe a new attempt
>>> with get a new reception.
>>
>> I can add my experience from the perspective of a user trying to get
>> early microcode loading to work with my system:
>>
>> First of all I can confirm that it sort of works - but as Jeremy has
>> pointed out, there seem to be issues with including it into the
>> initramfs. After many unsuccessful tries I also only got it to work
>> when I used a separate entry in multiboot (grub2) which referred to
>> the blob for uploading the payload to the CPU.
>>
>> As soon as I had the microcode integrated into the initramfs as
>> described at
>> http://lists.xen.org/archives/html/xen-devel/2013-09/msg02902.html
>> the system would no longer boot with a message stating that it could
>> not find the root filesystem - I assume that was at the time when
>> the initramfs was about to be unpacked and loaded (if I recall
>> correctly there were no messages from the initramfs on screen).
>> Therefore I couldn't verify whether the microcode was actually
>> lodaded before that.
>
> Hm, that would imply that Linux couldn't skip past the 'non-gzip'
> payload of the initramfs. But it does work for me so I am wondering
> what I am doing differently.
>
> Could you send an email with your .config and perhaps your serial log
> if you still have it?
.config on its way to your email address; if you require the serial log 
I would need to set that up and that would probably take a bit of time.
>
>
>>
>> My feeling at that time was that the unpacking of the initramfs had
>> failed and it was probably more a linux issue rather than a XEN
>> issue - albeit the concatenated file which per the link above should
>> be created by
>>
>> "cat ucode.cpio /boot/initrd-3.5.0.img >/boot/initrd-3.5.0.ucode.img"
>>
>> does not resemble a valid cpio archive any longer (you also can't
>> work with it on the command line - e.g. list its content). I assume
>> that though the kernel expects a valid cpio format file and
>> therefore is unable to unpack and subsequently fails.
>
> It should skip the bits that it does not understand.
Also on the CLI? I did another test right now:

cat /boot/microcode.bin /boot/initrd-3.11.7-hardened-r1.gz > 
/tmp/initrd-3.11.7-hardened-r1.gz

Now the initrd is prepended by the microcode. But when I do

zcat /tmp/initrd-3.11.7-hardened-r1.gz | cpio -itv

I get errors output from both gzip and cpio as follows:

gzip: /tmp/initrd-3.11.7-hardened-r1.gz: not in gzip format
cpio: premature end of archive

And to me that makes sense - how would gzip know how to deal with a 
compressed image file prepended by an uncompressed part without knowing 
the internal structure (i.e. at least its length). And cpio is not able 
to unpack because it doesn't get valid input from gzip through the pipe.

Unless you say that the initrd can't be compressed - that would on the 
face of it probably make sense, but even then a test with cpio failed 
with errors.
>>
>> But in any case, with the additional file in multiboot it works
>> flawlessly. The only catch is that the file distributed by Intel
>> (the microcode.dat which is a text file) has to be converted inot a
>> binary file (I also stripped it down to only contain the parts
>> necessary for my CPU, but I don't know whether that's strictly
>> necessary). And it must _NOT_ be a cpio archive in that case.
>
> You should be able to do 'cat /lib/firmware/intel_ucode/* > /boot/microcode.blob'
> and that would do it too.
I was not aware of that and had a hard time finding a solution. 
Initially I thought the microcode.dat from Intel's website could be used 
as is.
>
>>
>> Searching google there are a few tools available to convert the
>> Intel distributed microcode.dat to binary format and reduce it to
>> only the parts required for a specific CPU.
>>
>> Regards Atom2
I actually downloaded the source of a tool called iucode_tool-1.0.1 
(don't ask me from where) and compiled it. There are two advantages to 
that approach:
Firstly you can build from the Intel website's microcode.dat and you 
don't have to wait until your distro (in my case gentoo which are 
usually anyways pretty quick) makes the latest code available through 
their regular distribution system.
Secondly iucode_tool  also provides an option to only extract the code 
required for a specific processor (defaults to the one in the PC) and 
thus makes the file much smaller (in my case it's only 10,240 bytes as 
opposed to 576,512 bytes compared to the cat /lib/firmware/... above).

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

Re: How many patches are missing in upstream Linux?

[Konrad Rzeszutek Wilk]

On Tue, Mar 11, 2014 at 07:35:55PM +0100, Atom2 wrote:
> 
> 
> Am 11.03.14 18:53, schrieb Konrad Rzeszutek Wilk:
> >On Tue, Mar 11, 2014 at 06:38:52PM +0100, Atom2 wrote:
> >>
> >>
> >>Am 10.03.14 21:55, schrieb Jeremy Fitzhardinge:
> >>[snip]
> >>>>The maintainer is being <insert your own opinion here>:
> >>>>  - runtime microcode. What I had been told was to use the 'early
> >>>>    microcode' mechanism - which is now implemented and Xen can also scan
> >>>>    the initramfs to extract the microcode payload and apply it.
> >>>
> >>>I've never got that to work, but ucode=-1 with a microcode.dat multiboot
> >>>modules works pretty well.
> >>>
> >>>>    But it misses the important part of server longevity in that the
> >>>>    host might be running for years and the microcode might need to be
> >>>>    updated during that time. bpetkov wasn't too thrilled about the
> >>>>    runtime microcode and I hadn't come back to this yet to figure out
> >>>>    what are his exact technical misgivings.
> >>>
> >>>I think, in the end, he (and Ingo) were advocating just doing a full
> >>>emulation of the Intel/AMD update mechanism in the set/getmsr PV
> >>>callbacks. Which is doable but... well, not pretty. Maybe a new attempt
> >>>with get a new reception.
> >>
> >>I can add my experience from the perspective of a user trying to get
> >>early microcode loading to work with my system:
> >>
> >>First of all I can confirm that it sort of works - but as Jeremy has
> >>pointed out, there seem to be issues with including it into the
> >>initramfs. After many unsuccessful tries I also only got it to work
> >>when I used a separate entry in multiboot (grub2) which referred to
> >>the blob for uploading the payload to the CPU.
> >>
> >>As soon as I had the microcode integrated into the initramfs as
> >>described at
> >>http://lists.xen.org/archives/html/xen-devel/2013-09/msg02902.html
> >>the system would no longer boot with a message stating that it could
> >>not find the root filesystem - I assume that was at the time when
> >>the initramfs was about to be unpacked and loaded (if I recall
> >>correctly there were no messages from the initramfs on screen).
> >>Therefore I couldn't verify whether the microcode was actually
> >>lodaded before that.
> >
> >Hm, that would imply that Linux couldn't skip past the 'non-gzip'
> >payload of the initramfs. But it does work for me so I am wondering
> >what I am doing differently.
> >
> >Could you send an email with your .config and perhaps your serial log
> >if you still have it?
> .config on its way to your email address; if you require the serial
> log I would need to set that up and that would probably take a bit
> of time.

I think I do need that.
I took a peek at it and tweaked my kernel to have similar
options - that is disable the CONFIG_MICROCODE_EARLY in the kernel.
Have similar initramfs.

And this is what I boot with:
[konrad@build-external tst031]$ cpio -it -F initramfs.cpio.gz 
.
kernel
kernel/x86
kernel/x86/microcode
kernel/x86/microcode/GenuineIntel.bin
kernel/x86/microcode/AuthenticAMD.bin
1037 blocks
[konrad@build-external tst031]$ file initramfs.cpio.gz 
initramfs.cpio.gz: ASCII cpio archive (SVR4 with no CRC)

And Linux has no problems booting with it. Neither does
Xen + Linux with 'ucode=scan' or without that option.

Xen sees it:
(XEN)  Init. ramdisk: ffffffff823f9000->ffffffff87858606
Linux sees it:
[    0.000000] RAMDISK: [mem 0x023f9000-0x07858fff]
then unpacks it:
[   13.261414] Unpacking initramfs...
[   15.735168] Freeing initrd memory: 86400K (ffff8800023f9000 - ffff880007859000)

so not sure what to make out of it.

Is the ramdisk of yours a special filesystem? (Can you have squash/etc
filesystems on ramdisks?)
> >
> >
> >>
> >>My feeling at that time was that the unpacking of the initramfs had
> >>failed and it was probably more a linux issue rather than a XEN
> >>issue - albeit the concatenated file which per the link above should
> >>be created by
> >>
> >>"cat ucode.cpio /boot/initrd-3.5.0.img >/boot/initrd-3.5.0.ucode.img"
> >>
> >>does not resemble a valid cpio archive any longer (you also can't
> >>work with it on the command line - e.g. list its content). I assume
> >>that though the kernel expects a valid cpio format file and
> >>therefore is unable to unpack and subsequently fails.
> >
> >It should skip the bits that it does not understand.
> Also on the CLI? I did another test right now:
> 
> cat /boot/microcode.bin /boot/initrd-3.11.7-hardened-r1.gz >
> /tmp/initrd-3.11.7-hardened-r1.gz
> 
> Now the initrd is prepended by the microcode. But when I do
> 
> zcat /tmp/initrd-3.11.7-hardened-r1.gz | cpio -itv
> 
> I get errors output from both gzip and cpio as follows:
> 
> gzip: /tmp/initrd-3.11.7-hardened-r1.gz: not in gzip format
> cpio: premature end of archive
> 
> And to me that makes sense - how would gzip know how to deal with a
> compressed image file prepended by an uncompressed part without
> knowing the internal structure (i.e. at least its length). And cpio
> is not able to unpack because it doesn't get valid input from gzip
> through the pipe.
> 
> Unless you say that the initrd can't be compressed - that would on
> the face of it probably make sense, but even then a test with cpio
> failed with errors.

What about itself without the 'z' in? So cat /tmp/init.. | cpio -itv?
You should see some files.

> >>
> >>But in any case, with the additional file in multiboot it works
> >>flawlessly. The only catch is that the file distributed by Intel
> >>(the microcode.dat which is a text file) has to be converted inot a
> >>binary file (I also stripped it down to only contain the parts
> >>necessary for my CPU, but I don't know whether that's strictly
> >>necessary). And it must _NOT_ be a cpio archive in that case.
> >
> >You should be able to do 'cat /lib/firmware/intel_ucode/* > /boot/microcode.blob'
> >and that would do it too.
> I was not aware of that and had a hard time finding a solution.
> Initially I thought the microcode.dat from Intel's website could be
> used as is.
> >
> >>
> >>Searching google there are a few tools available to convert the
> >>Intel distributed microcode.dat to binary format and reduce it to
> >>only the parts required for a specific CPU.
> >>
> >>Regards Atom2
> I actually downloaded the source of a tool called iucode_tool-1.0.1
> (don't ask me from where) and compiled it. There are two advantages
> to that approach:
> Firstly you can build from the Intel website's microcode.dat and you
> don't have to wait until your distro (in my case gentoo which are
> usually anyways pretty quick) makes the latest code available
> through their regular distribution system.
> Secondly iucode_tool  also provides an option to only extract the
> code required for a specific processor (defaults to the one in the
> PC) and thus makes the file much smaller (in my case it's only
> 10,240 bytes as opposed to 576,512 bytes compared to the cat
> /lib/firmware/... above).

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

Re: How many patches are missing in upstream Linux?

[Atom2]

I made some progress and there's good and bad news - see further below:

Am 11.03.14 21:33, schrieb Konrad Rzeszutek Wilk:
> On Tue, Mar 11, 2014 at 07:35:55PM +0100, Atom2 wrote:
>>
>>
>> Am 11.03.14 18:53, schrieb Konrad Rzeszutek Wilk:
>>> On Tue, Mar 11, 2014 at 06:38:52PM +0100, Atom2 wrote:
>>>>
>>>>
>>>> Am 10.03.14 21:55, schrieb Jeremy Fitzhardinge:
>>>> [snip]
>>>>>> The maintainer is being <insert your own opinion here>:
>>>>>>   - runtime microcode. What I had been told was to use the 'early
>>>>>>     microcode' mechanism - which is now implemented and Xen can also scan
>>>>>>     the initramfs to extract the microcode payload and apply it.
>>>>>
>>>>> I've never got that to work, but ucode=-1 with a microcode.dat multiboot
>>>>> modules works pretty well.
>>>>>
>>>>>>     But it misses the important part of server longevity in that the
>>>>>>     host might be running for years and the microcode might need to be
>>>>>>     updated during that time. bpetkov wasn't too thrilled about the
>>>>>>     runtime microcode and I hadn't come back to this yet to figure out
>>>>>>     what are his exact technical misgivings.
>>>>>
>>>>> I think, in the end, he (and Ingo) were advocating just doing a full
>>>>> emulation of the Intel/AMD update mechanism in the set/getmsr PV
>>>>> callbacks. Which is doable but... well, not pretty. Maybe a new attempt
>>>>> with get a new reception.
>>>>
>>>> I can add my experience from the perspective of a user trying to get
>>>> early microcode loading to work with my system:
>>>>
>>>> First of all I can confirm that it sort of works - but as Jeremy has
>>>> pointed out, there seem to be issues with including it into the
>>>> initramfs. After many unsuccessful tries I also only got it to work
>>>> when I used a separate entry in multiboot (grub2) which referred to
>>>> the blob for uploading the payload to the CPU.
>>>>
>>>> As soon as I had the microcode integrated into the initramfs as
>>>> described at
>>>> http://lists.xen.org/archives/html/xen-devel/2013-09/msg02902.html
>>>> the system would no longer boot with a message stating that it could
>>>> not find the root filesystem - I assume that was at the time when
>>>> the initramfs was about to be unpacked and loaded (if I recall
>>>> correctly there were no messages from the initramfs on screen).
>>>> Therefore I couldn't verify whether the microcode was actually
>>>> lodaded before that.
>>>
>>> Hm, that would imply that Linux couldn't skip past the 'non-gzip'
>>> payload of the initramfs. But it does work for me so I am wondering
>>> what I am doing differently.
>>>
>>> Could you send an email with your .config and perhaps your serial log
>>> if you still have it?
>> .config on its way to your email address; if you require the serial
>> log I would need to set that up and that would probably take a bit
>> of time.
>
> I think I do need that.
> I took a peek at it and tweaked my kernel to have similar
> options - that is disable the CONFIG_MICROCODE_EARLY in the kernel.
> Have similar initramfs.
Looking at the output of the serial console there are a few interesting 
message lines in there as follows:

[5.104573] Unpacking initramfs...
[5.104578] Initramfs unpacking failed: incorrect cpio method used; use 
-H newc option
[5.105969] Freeing initrd memory: 3716k (ffff880001e00000 - 
ffff8800021a1000)
>
> And this is what I boot with:
> [konrad@build-external tst031]$ cpio -it -F initramfs.cpio.gz
> .
> kernel
> kernel/x86
> kernel/x86/microcode
> kernel/x86/microcode/GenuineIntel.bin
> kernel/x86/microcode/AuthenticAMD.bin
> 1037 blocks
There was an error in my last try and the command above which worked at 
your end has actually always worked at my end as well. When it (rightly 
failed) in my last try I had mistakenly prepended the binary blob file 
and not the cpio archive containing the GenuineIntel.bin file (see my 
command further below) - but that was not the inherent problem to the 
failed boot attempts.
> [konrad@build-external tst031]$ file initramfs.cpio.gz
> initramfs.cpio.gz: ASCII cpio archive (SVR4 with no CRC)
Now there's a difference with my file:

# file /boot/initrd-3.11.7-hardened-r1-ucode.gz
/boot/initrd-3.11.7-hardened-r1-ucode.gz: ASCII cpio archive (pre-SVR4 
or odc)

I had created my file with cpio -oc (which is also what you suggested in 
the mail I linked above) and according to my memory and the man 
documents on the net (e.g. http://linux.die.net/man/1/cpio; the online 
man page only refers to info which I personally don't like) -c is 
equivalent to -H newc ... so what the heck is going on

But then I thought there's no harm in giving -H newc a try instead of -c 
and suddenly the file format changed to "SRV with no CRC". On further 
investigation I found out (through the behated info pages) that -c no 
longer is equivalent to -H newc but rather indicates "use the old 
portable format" whereas -H newc refers to the "new (SRV4) portable 
format". So there has been a change in the meaning of the -c option 
somewhen.

Now with the new portable format booting works from the modified initrd 
and the kernel obviously knows how to skip the start of the file with 
the uncompressed cpio archive. So far so good - and that's the good news.

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 Linux has no problems booting with it. Neither does
> Xen + Linux with 'ucode=scan' or without that option.
>
> Xen sees it:
> (XEN)  Init. ramdisk: ffffffff823f9000->ffffffff87858606
> Linux sees it:
> [    0.000000] RAMDISK: [mem 0x023f9000-0x07858fff]
> then unpacks it:
> [   13.261414] Unpacking initramfs...
> [   15.735168] Freeing initrd memory: 86400K (ffff8800023f9000 - ffff880007859000)
>
> so not sure what to make out of it.
>
> Is the ramdisk of yours a special filesystem? (Can you have squash/etc
> filesystems on ramdisks?)
>>>
>>>
>>>>
>>>> My feeling at that time was that the unpacking of the initramfs had
>>>> failed and it was probably more a linux issue rather than a XEN
>>>> issue - albeit the concatenated file which per the link above should
>>>> be created by
>>>>
>>>> "cat ucode.cpio /boot/initrd-3.5.0.img >/boot/initrd-3.5.0.ucode.img"
>>>>
>>>> does not resemble a valid cpio archive any longer (you also can't
>>>> work with it on the command line - e.g. list its content). I assume
>>>> that though the kernel expects a valid cpio format file and
>>>> therefore is unable to unpack and subsequently fails.
>>>
>>> It should skip the bits that it does not understand.
>> Also on the CLI? I did another test right now:
>>
>> cat /boot/microcode.bin /boot/initrd-3.11.7-hardened-r1.gz >
>> /tmp/initrd-3.11.7-hardened-r1.gz
This was where my error referred to earlier came from - I prepended the 
microcode file and not a cpio archive.
>>
>> Now the initrd is prepended by the microcode. But when I do
>>
>> zcat /tmp/initrd-3.11.7-hardened-r1.gz | cpio -itv
>>
>> I get errors output from both gzip and cpio as follows:
>>
>> gzip: /tmp/initrd-3.11.7-hardened-r1.gz: not in gzip format
>> cpio: premature end of archive
>>
>> And to me that makes sense - how would gzip know how to deal with a
>> compressed image file prepended by an uncompressed part without
>> knowing the internal structure (i.e. at least its length). And cpio
>> is not able to unpack because it doesn't get valid input from gzip
>> through the pipe.
>>
>> Unless you say that the initrd can't be compressed - that would on
>> the face of it probably make sense, but even then a test with cpio
>> failed with errors.
>
> What about itself without the 'z' in? So cat /tmp/init.. | cpio -itv?
> You should see some files.
>
>>>>
>>>> But in any case, with the additional file in multiboot it works
>>>> flawlessly. The only catch is that the file distributed by Intel
>>>> (the microcode.dat which is a text file) has to be converted inot a
>>>> binary file (I also stripped it down to only contain the parts
>>>> necessary for my CPU, but I don't know whether that's strictly
>>>> necessary). And it must _NOT_ be a cpio archive in that case.
>>>
>>> You should be able to do 'cat /lib/firmware/intel_ucode/* > /boot/microcode.blob'
>>> and that would do it too.
>> I was not aware of that and had a hard time finding a solution.
>> Initially I thought the microcode.dat from Intel's website could be
>> used as is.
>>>
>>>>
>>>> Searching google there are a few tools available to convert the
>>>> Intel distributed microcode.dat to binary format and reduce it to
>>>> only the parts required for a specific CPU.
>>>>
>>>> Regards Atom2
>> I actually downloaded the source of a tool called iucode_tool-1.0.1
>> (don't ask me from where) and compiled it. There are two advantages
>> to that approach:
>> Firstly you can build from the Intel website's microcode.dat and you
>> don't have to wait until your distro (in my case gentoo which are
>> usually anyways pretty quick) makes the latest code available
>> through their regular distribution system.
>> Secondly iucode_tool  also provides an option to only extract the
>> code required for a specific processor (defaults to the one in the
>> PC) and thus makes the file much smaller (in my case it's only
>> 10,240 bytes as opposed to 576,512 bytes compared to the cat
>> /lib/firmware/... above).
>
> Right.
>>
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xen.org
>>> http://lists.xen.org/xen-devel
>>>

Re: How many patches are missing in upstream Linux?

[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.

Jan

Re: How many patches are missing in upstream Linux?

[Atom2]

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

Re: How many patches are missing in upstream Linux?

[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.

> dmesg2 - that's the one where the update doesn't work
> | (XEN) Command line: placeholder ucode=scan vga=gfx-1024x768x32 i915.m

Nor here.

I also don't see what an i915 option has to do on the hypervisor
command line - are you perhaps mixing up which options need to
go where?

Jan

Re: How many patches are missing in upstream Linux?

[Atom2]

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 also don't see what an i915 option has to do on the hypervisor
> command line - are you perhaps mixing up which options need to
> go where?
That may be a leftover from the install prior to xen - it shouldn't do 
any harm though and I am more than happy to remove it; just in case you 
find any other option that shouldn't be there just tell me, I am happy 
to learn ...
>
> Jan
>

Re: How many patches are missing in upstream Linux?

[Konrad Rzeszutek Wilk]

[-- 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

Re: How many patches are missing in upstream Linux?

[Atom2]

Am 12.03.14 14:50, schrieb Konrad Rzeszutek Wilk:
> On Wed, Mar 12, 2014 at 12:58:13PM +0100, Atom2 wrote:
> 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.
I'd be very happy to be of help here - but, and that appears to be odd, 
my version of xen does _NOT_ contain a function microcode_scan_module. 
So your patch won't apply and fails for hunk #2 and #3:

# patch -p1 --dry-run < microcode-debug.patch
(Stripping trailing CRs from patch.)
patching file xen/arch/x86/microcode.c
Hunk #2 FAILED at 138.
Hunk #3 FAILED at 155.
2 out of 3 hunks FAILED -- saving rejects to file 
xen/arch/x86/microcode.c.rej
(Stripping trailing CRs from patch.)
patching file xen/arch/x86/microcode_intel.c

On the other hand I guess that missing function certainly does explain 
why the system can't scan and thus can't find the payload included in 
the module. So in the end, I guess I nevertheless have been able to 
somehow help ... (:-)

As the update with a separate module (multiboot) works, the rest of the 
infrastructure for microcode updates seems to be there and working.

Is the function microcode_scan_module not part of the upstream xen that 
is being used by distributions? Or did just gentoo miss something here - 
although Jeremy also said that he was unable to get it to work unless 
provided in a separate file? Though I have no clue what distribution he 
is using ...

BTW the version of XEN I'm using is 4.3.1-r5 (the latest stable version 
of gentoo).
>
> 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

Re: How many patches are missing in upstream Linux?

[Konrad Rzeszutek Wilk]

On Wed, Mar 12, 2014 at 04:09:20PM +0100, Atom2 wrote:
> 
> 
> Am 12.03.14 14:50, schrieb Konrad Rzeszutek Wilk:
> >On Wed, Mar 12, 2014 at 12:58:13PM +0100, Atom2 wrote:
> >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.
> I'd be very happy to be of help here - but, and that appears to be
> odd, my version of xen does _NOT_ contain a function
> microcode_scan_module. So your patch won't apply and fails for hunk
> #2 and #3:
> 
> # patch -p1 --dry-run < microcode-debug.patch
> (Stripping trailing CRs from patch.)
> patching file xen/arch/x86/microcode.c
> Hunk #2 FAILED at 138.
> Hunk #3 FAILED at 155.
> 2 out of 3 hunks FAILED -- saving rejects to file
> xen/arch/x86/microcode.c.rej
> (Stripping trailing CRs from patch.)
> patching file xen/arch/x86/microcode_intel.c
> 
> On the other hand I guess that missing function certainly does
> explain why the system can't scan and thus can't find the payload
> included in the module. So in the end, I guess I nevertheless have
> been able to somehow help ... (:-)

Hehe.
> 
> As the update with a separate module (multiboot) works, the rest of
> the infrastructure for microcode updates seems to be there and
> working.
> 
> Is the function microcode_scan_module not part of the upstream xen
> that is being used by distributions? Or did just gentoo miss
> something here - although Jeremy also said that he was unable to get
> it to work unless provided in a separate file? Though I have no clue
> what distribution he is using ...
> 
> BTW the version of XEN I'm using is 4.3.1-r5 (the latest stable
> version of gentoo).

Right. And Xen 4.4 is the one that got the ucode=scan code support :-)

> >
> >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