Current state of Xen microcode (Was: Re: uploading 3.16~rc5-1~exp1)

Current state of Xen microcode (Was: Re: uploading 3.16~rc5-1~exp1)

[Ian Campbell]

Adding xen-devel and some of the Linux maints,

On Mon, 2014-07-14 at 23:22 +0200, maximilian attems wrote:
> I will upload tomorrow Tuesday around 22h00 UT to experimental.
> 
> There are two TODOS concerning the not yet forwarded Debian patches:
> - cgroups
> - xen microcode
> 
> 
> I consider both not a blocker, but would be happy if Xen guys could
> have a look for what is needed.

The xen microcode patches which maks is referring to are these:
http://anonscm.debian.org/viewvc/kernel/dists/trunk/linux/debian/patches/features/all/xen/
which are a forward port of Jeremy's old microcode_xen.ko driver.

I've not been keeping up on Xen x86 microcode stuff these days but I
think we don't need this any more with modern Xen since we can parse the
microcode blob off the front of the initrd, is that right?

(this is predicated on Xen 4.4 hitting unstable, which is underway)

Thanks,
Ian.

Re: Current state of Xen microcode (Was: Re: uploading 3.16~rc5-1~exp1)

[Konrad Rzeszutek Wilk]

On Tue, Jul 15, 2014 at 09:53:32AM +0100, Ian Campbell wrote:
> Adding xen-devel and some of the Linux maints,
> 
> On Mon, 2014-07-14 at 23:22 +0200, maximilian attems wrote:
> > I will upload tomorrow Tuesday around 22h00 UT to experimental.
> > 
> > There are two TODOS concerning the not yet forwarded Debian patches:
> > - cgroups
> > - xen microcode
> > 
> > 
> > I consider both not a blocker, but would be happy if Xen guys could
> > have a look for what is needed.
> 
> The xen microcode patches which maks is referring to are these:
> http://anonscm.debian.org/viewvc/kernel/dists/trunk/linux/debian/patches/features/all/xen/
> which are a forward port of Jeremy's old microcode_xen.ko driver.

They are also at my branch
http://git.kernel.org/cgit/linux/kernel/git/konrad/xen.git/log/?h=stable/misc

Hm, I should rebase them at some point.
> 
> I've not been keeping up on Xen x86 microcode stuff these days but I
> think we don't need this any more with modern Xen since we can parse the
> microcode blob off the front of the initrd, is that right?

Right. And best of it, the support for that is in dracut so
it automatically can happen (thought you still need to add
'ucode=scan' in the /etc/default/grub.cfg in the GRUB_CMDLINE_XEN
parameter) and also in /etc/dracut.conf add 'early_microcode=yes'.

> 
> (this is predicated on Xen 4.4 hitting unstable, which is underway)

unstable == Debian unstable?

> 
> Thanks,
> Ian.
> 

Re: Current state of Xen microcode (Was: Re: uploading 3.16~rc5-1~exp1)

[Ian Campbell]

On Tue, 2014-07-15 at 10:59 -0400, Konrad Rzeszutek Wilk wrote:
> On Tue, Jul 15, 2014 at 09:53:32AM +0100, Ian Campbell wrote:
> > Adding xen-devel and some of the Linux maints,
> > 
> > On Mon, 2014-07-14 at 23:22 +0200, maximilian attems wrote:
> > > I will upload tomorrow Tuesday around 22h00 UT to experimental.
> > > 
> > > There are two TODOS concerning the not yet forwarded Debian patches:
> > > - cgroups
> > > - xen microcode
> > > 
> > > 
> > > I consider both not a blocker, but would be happy if Xen guys could
> > > have a look for what is needed.
> > 
> > The xen microcode patches which maks is referring to are these:
> > http://anonscm.debian.org/viewvc/kernel/dists/trunk/linux/debian/patches/features/all/xen/
> > which are a forward port of Jeremy's old microcode_xen.ko driver.
> 
> They are also at my branch
> http://git.kernel.org/cgit/linux/kernel/git/konrad/xen.git/log/?h=stable/misc
> 
> Hm, I should rebase them at some point.
> > 
> > I've not been keeping up on Xen x86 microcode stuff these days but I
> > think we don't need this any more with modern Xen since we can parse the
> > microcode blob off the front of the initrd, is that right?
> 
> Right. And best of it, the support for that is in dracut so
> it automatically can happen (thought you still need to add
> 'ucode=scan' in the /etc/default/grub.cfg in the GRUB_CMDLINE_XEN
> parameter) and also in /etc/dracut.conf add 'early_microcode=yes'.

Hrm, I thought it was transparent. Debian doesn't use dracut, it uses
initramfs-tools. So perhaps there is some work to be done here.

I understand ucode=scan, but what does the dracut option do?

> > (this is predicated on Xen 4.4 hitting unstable, which is underway)
> 
> unstable == Debian unstable?

Yes.

Ian.

Re: Current state of Xen microcode (Was: Re: uploading 3.16~rc5-1~exp1)

[Konrad Rzeszutek Wilk]

On Tue, Jul 15, 2014 at 04:06:00PM +0100, Ian Campbell wrote:
> On Tue, 2014-07-15 at 10:59 -0400, Konrad Rzeszutek Wilk wrote:
> > On Tue, Jul 15, 2014 at 09:53:32AM +0100, Ian Campbell wrote:
> > > Adding xen-devel and some of the Linux maints,
> > > 
> > > On Mon, 2014-07-14 at 23:22 +0200, maximilian attems wrote:
> > > > I will upload tomorrow Tuesday around 22h00 UT to experimental.
> > > > 
> > > > There are two TODOS concerning the not yet forwarded Debian patches:
> > > > - cgroups
> > > > - xen microcode
> > > > 
> > > > 
> > > > I consider both not a blocker, but would be happy if Xen guys could
> > > > have a look for what is needed.
> > > 
> > > The xen microcode patches which maks is referring to are these:
> > > http://anonscm.debian.org/viewvc/kernel/dists/trunk/linux/debian/patches/features/all/xen/
> > > which are a forward port of Jeremy's old microcode_xen.ko driver.
> > 
> > They are also at my branch
> > http://git.kernel.org/cgit/linux/kernel/git/konrad/xen.git/log/?h=stable/misc
> > 
> > Hm, I should rebase them at some point.
> > > 
> > > I've not been keeping up on Xen x86 microcode stuff these days but I
> > > think we don't need this any more with modern Xen since we can parse the
> > > microcode blob off the front of the initrd, is that right?
> > 
> > Right. And best of it, the support for that is in dracut so
> > it automatically can happen (thought you still need to add
> > 'ucode=scan' in the /etc/default/grub.cfg in the GRUB_CMDLINE_XEN
> > parameter) and also in /etc/dracut.conf add 'early_microcode=yes'.
> 
> Hrm, I thought it was transparent. Debian doesn't use dracut, it uses
> initramfs-tools. So perhaps there is some work to be done here.
> 
> I understand ucode=scan, but what does the dracut option do?

Packages the blobs and sticks them to the initramfs.

I think 'initframfs-tools' will need some code there. Here is what
I did in dracut:

http://git.kernel.org/cgit/boot/dracut/dracut.git/commit/?id=5f2c30d9bcd614d546d5c55c6897e33f88b9ab90

http://git.kernel.org/cgit/boot/dracut/dracut.git/commit/?id=b5b608e44ade93bee54d274f5edc6aad6dc45288

http://git.kernel.org/cgit/boot/dracut/dracut.git/commit/?id=d8b04dc1840047a7533d19f577f30f19d42e2d33
> 
> > > (this is predicated on Xen 4.4 hitting unstable, which is underway)
> > 
> > unstable == Debian unstable?
> 
> Yes.
> 
> Ian.
> 

Re: Current state of Xen microcode (Was: Re: uploading 3.16~rc5-1~exp1)

[Ian Campbell]

On Tue, 2014-07-15 at 11:35 -0400, Konrad Rzeszutek Wilk wrote:
> On Tue, Jul 15, 2014 at 04:06:00PM +0100, Ian Campbell wrote:
> > On Tue, 2014-07-15 at 10:59 -0400, Konrad Rzeszutek Wilk wrote:
> > > On Tue, Jul 15, 2014 at 09:53:32AM +0100, Ian Campbell wrote:
> > > > Adding xen-devel and some of the Linux maints,
> > > > 
> > > > On Mon, 2014-07-14 at 23:22 +0200, maximilian attems wrote:
> > > > > I will upload tomorrow Tuesday around 22h00 UT to experimental.
> > > > > 
> > > > > There are two TODOS concerning the not yet forwarded Debian patches:
> > > > > - cgroups
> > > > > - xen microcode
> > > > > 
> > > > > 
> > > > > I consider both not a blocker, but would be happy if Xen guys could
> > > > > have a look for what is needed.
> > > > 
> > > > The xen microcode patches which maks is referring to are these:
> > > > http://anonscm.debian.org/viewvc/kernel/dists/trunk/linux/debian/patches/features/all/xen/
> > > > which are a forward port of Jeremy's old microcode_xen.ko driver.
> > > 
> > > They are also at my branch
> > > http://git.kernel.org/cgit/linux/kernel/git/konrad/xen.git/log/?h=stable/misc
> > > 
> > > Hm, I should rebase them at some point.
> > > > 
> > > > I've not been keeping up on Xen x86 microcode stuff these days but I
> > > > think we don't need this any more with modern Xen since we can parse the
> > > > microcode blob off the front of the initrd, is that right?
> > > 
> > > Right. And best of it, the support for that is in dracut so
> > > it automatically can happen (thought you still need to add
> > > 'ucode=scan' in the /etc/default/grub.cfg in the GRUB_CMDLINE_XEN
> > > parameter) and also in /etc/dracut.conf add 'early_microcode=yes'.
> > 
> > Hrm, I thought it was transparent. Debian doesn't use dracut, it uses
> > initramfs-tools. So perhaps there is some work to be done here.
> > 
> > I understand ucode=scan, but what does the dracut option do?
> 
> Packages the blobs and sticks them to the initramfs.

OK.

> I think 'initframfs-tools' will need some code there.

It already does the right thing automatically if the appropriate
microcode package is installed, so no need for an option.

So all which is needed is the ucode=scan I guess.

Ian.

Re: Current state of Xen microcode (Was: Re: uploading 3.16~rc5-1~exp1)

[Ben Hutchings]

[-- Attachment #1.1: Type: text/plain, Size: 2499 bytes --]

On Tue, 2014-07-15 at 11:35 -0400, Konrad Rzeszutek Wilk wrote:
> On Tue, Jul 15, 2014 at 04:06:00PM +0100, Ian Campbell wrote:
> > On Tue, 2014-07-15 at 10:59 -0400, Konrad Rzeszutek Wilk wrote:
> > > On Tue, Jul 15, 2014 at 09:53:32AM +0100, Ian Campbell wrote:
> > > > Adding xen-devel and some of the Linux maints,
> > > > 
> > > > On Mon, 2014-07-14 at 23:22 +0200, maximilian attems wrote:
> > > > > I will upload tomorrow Tuesday around 22h00 UT to experimental.
> > > > > 
> > > > > There are two TODOS concerning the not yet forwarded Debian patches:
> > > > > - cgroups
> > > > > - xen microcode
> > > > > 
> > > > > 
> > > > > I consider both not a blocker, but would be happy if Xen guys could
> > > > > have a look for what is needed.
> > > > 
> > > > The xen microcode patches which maks is referring to are these:
> > > > http://anonscm.debian.org/viewvc/kernel/dists/trunk/linux/debian/patches/features/all/xen/
> > > > which are a forward port of Jeremy's old microcode_xen.ko driver.
> > > 
> > > They are also at my branch
> > > http://git.kernel.org/cgit/linux/kernel/git/konrad/xen.git/log/?h=stable/misc
> > > 
> > > Hm, I should rebase them at some point.
> > > > 
> > > > I've not been keeping up on Xen x86 microcode stuff these days but I
> > > > think we don't need this any more with modern Xen since we can parse the
> > > > microcode blob off the front of the initrd, is that right?
> > > 
> > > Right. And best of it, the support for that is in dracut so
> > > it automatically can happen (thought you still need to add
> > > 'ucode=scan' in the /etc/default/grub.cfg in the GRUB_CMDLINE_XEN
> > > parameter) and also in /etc/dracut.conf add 'early_microcode=yes'.
> > 
> > Hrm, I thought it was transparent. Debian doesn't use dracut, it uses
> > initramfs-tools. So perhaps there is some work to be done here.
> > 
> > I understand ucode=scan, but what does the dracut option do?
> 
> Packages the blobs and sticks them to the initramfs.
> 
> I think 'initframfs-tools' will need some code there.
[...]

initramfs-tools can already prepend microcode in the way Linux expects.
I assume Xen supports the same format (it's a little weird for it to be
parsing the dom0 initrd, but OK...).  But we're presumably missing the
GRUB integration to get 'ucode=scan' added automatically.

Ben.

-- 
Ben Hutchings
Hoare's Law of Large Problems:
        Inside every large problem is a small problem struggling to get out.

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: Current state of Xen microcode (Was: Re: uploading 3.16~rc5-1~exp1)

[Konrad Rzeszutek Wilk]

On Tue, Jul 15, 2014 at 06:53:04PM +0100, Ben Hutchings wrote:
> On Tue, 2014-07-15 at 11:35 -0400, Konrad Rzeszutek Wilk wrote:
> > On Tue, Jul 15, 2014 at 04:06:00PM +0100, Ian Campbell wrote:
> > > On Tue, 2014-07-15 at 10:59 -0400, Konrad Rzeszutek Wilk wrote:
> > > > On Tue, Jul 15, 2014 at 09:53:32AM +0100, Ian Campbell wrote:
> > > > > Adding xen-devel and some of the Linux maints,
> > > > > 
> > > > > On Mon, 2014-07-14 at 23:22 +0200, maximilian attems wrote:
> > > > > > I will upload tomorrow Tuesday around 22h00 UT to experimental.
> > > > > > 
> > > > > > There are two TODOS concerning the not yet forwarded Debian patches:
> > > > > > - cgroups
> > > > > > - xen microcode
> > > > > > 
> > > > > > 
> > > > > > I consider both not a blocker, but would be happy if Xen guys could
> > > > > > have a look for what is needed.
> > > > > 
> > > > > The xen microcode patches which maks is referring to are these:
> > > > > http://anonscm.debian.org/viewvc/kernel/dists/trunk/linux/debian/patches/features/all/xen/
> > > > > which are a forward port of Jeremy's old microcode_xen.ko driver.
> > > > 
> > > > They are also at my branch
> > > > http://git.kernel.org/cgit/linux/kernel/git/konrad/xen.git/log/?h=stable/misc
> > > > 
> > > > Hm, I should rebase them at some point.
> > > > > 
> > > > > I've not been keeping up on Xen x86 microcode stuff these days but I
> > > > > think we don't need this any more with modern Xen since we can parse the
> > > > > microcode blob off the front of the initrd, is that right?
> > > > 
> > > > Right. And best of it, the support for that is in dracut so
> > > > it automatically can happen (thought you still need to add
> > > > 'ucode=scan' in the /etc/default/grub.cfg in the GRUB_CMDLINE_XEN
> > > > parameter) and also in /etc/dracut.conf add 'early_microcode=yes'.
> > > 
> > > Hrm, I thought it was transparent. Debian doesn't use dracut, it uses
> > > initramfs-tools. So perhaps there is some work to be done here.
> > > 
> > > I understand ucode=scan, but what does the dracut option do?
> > 
> > Packages the blobs and sticks them to the initramfs.
> > 
> > I think 'initframfs-tools' will need some code there.
> [...]
> 
> initramfs-tools can already prepend microcode in the way Linux expects.
> I assume Xen supports the same format (it's a little weird for it to be
> parsing the dom0 initrd, but OK...).  But we're presumably missing the

It scans all of the binary blobs that are attached looking for the
proper cpio signature. So you could do it as a seperate cpio binary.

Or a binary blob (cat /lib/firmware/*ucode/* > /boot/multiboot.bin)
and the 'multiboot.bin' can be part of the multiboot stanza:
	module /multiboot.bin

And you add 'ucode=-1' for it to take the last module and use that
as its source of microcode code.

However, the 'ucode=scan' is more in line with what Linux has with
the early microcode loading so you are better of using that and
it will be less work.
> GRUB integration to get 'ucode=scan' added automatically.

<nods>
> 
> Ben.
> 
> -- 
> Ben Hutchings
> Hoare's Law of Large Problems:
>         Inside every large problem is a small problem struggling to get out.

Re: Current state of Xen microcode (Was: Re: uploading 3.16~rc5-1~exp1)

[Jan Beulich]

>>> On 15.07.14 at 16:59, <konrad.wilk@oracle.com> wrote:
> On Tue, Jul 15, 2014 at 09:53:32AM +0100, Ian Campbell wrote:
>> Adding xen-devel and some of the Linux maints,
>> 
>> On Mon, 2014-07-14 at 23:22 +0200, maximilian attems wrote:
>> > I will upload tomorrow Tuesday around 22h00 UT to experimental.
>> > 
>> > There are two TODOS concerning the not yet forwarded Debian patches:
>> > - cgroups
>> > - xen microcode
>> > 
>> > 
>> > I consider both not a blocker, but would be happy if Xen guys could
>> > have a look for what is needed.
>> 
>> The xen microcode patches which maks is referring to are these:
>> 
> http://anonscm.debian.org/viewvc/kernel/dists/trunk/linux/debian/patches/feat 
> ures/all/xen/
>> which are a forward port of Jeremy's old microcode_xen.ko driver.
> 
> They are also at my branch
> http://git.kernel.org/cgit/linux/kernel/git/konrad/xen.git/log/?h=stable/mis 
> c
> 
> Hm, I should rebase them at some point.
>> 
>> I've not been keeping up on Xen x86 microcode stuff these days but I
>> think we don't need this any more with modern Xen since we can parse the
>> microcode blob off the front of the initrd, is that right?
> 
> Right. And best of it, the support for that is in dracut so
> it automatically can happen (thought you still need to add
> 'ucode=scan' in the /etc/default/grub.cfg in the GRUB_CMDLINE_XEN
> parameter) and also in /etc/dracut.conf add 'early_microcode=yes'.

Except that all this still doesn't take care of updating microcode at
runtime. Yet that should - like kexec - be implemented in the
respective tools such that no kernel involvement it required.

Jan

Re: Current state of Xen microcode (Was: Re: uploading 3.16~rc5-1~exp1)

[Konrad Rzeszutek Wilk]

On Wed, Jul 23, 2014 at 03:59:37PM +0100, Jan Beulich wrote:
> >>> On 15.07.14 at 16:59, <konrad.wilk@oracle.com> wrote:
> > On Tue, Jul 15, 2014 at 09:53:32AM +0100, Ian Campbell wrote:
> >> Adding xen-devel and some of the Linux maints,
> >> 
> >> On Mon, 2014-07-14 at 23:22 +0200, maximilian attems wrote:
> >> > I will upload tomorrow Tuesday around 22h00 UT to experimental.
> >> > 
> >> > There are two TODOS concerning the not yet forwarded Debian patches:
> >> > - cgroups
> >> > - xen microcode
> >> > 
> >> > 
> >> > I consider both not a blocker, but would be happy if Xen guys could
> >> > have a look for what is needed.
> >> 
> >> The xen microcode patches which maks is referring to are these:
> >> 
> > http://anonscm.debian.org/viewvc/kernel/dists/trunk/linux/debian/patches/feat 
> > ures/all/xen/
> >> which are a forward port of Jeremy's old microcode_xen.ko driver.
> > 
> > They are also at my branch
> > http://git.kernel.org/cgit/linux/kernel/git/konrad/xen.git/log/?h=stable/mis 
> > c
> > 
> > Hm, I should rebase them at some point.
> >> 
> >> I've not been keeping up on Xen x86 microcode stuff these days but I
> >> think we don't need this any more with modern Xen since we can parse the
> >> microcode blob off the front of the initrd, is that right?
> > 
> > Right. And best of it, the support for that is in dracut so
> > it automatically can happen (thought you still need to add
> > 'ucode=scan' in the /etc/default/grub.cfg in the GRUB_CMDLINE_XEN
> > parameter) and also in /etc/dracut.conf add 'early_microcode=yes'.
> 
> Except that all this still doesn't take care of updating microcode at
> runtime. Yet that should - like kexec - be implemented in the
> respective tools such that no kernel involvement it required.

What are such tools? My recollection is that it is matter of
sticking the files in /lib/firmware and then udev - will try
at the detection of an CPU becoming online, do:
 - load microcode module
 - echo 1 > to the 'reload' sysfs parameter

Perhaps the solution is simple:
 - write an xen userspace tool that will do this loading via
   the hypercalls.
 - plug said tool in the udev script that comes with xen.
 - distros will install said udev scripts when they install Xen rpms?

That sounds too simple to be true. I must be missing something :-)
> 
> Jan
> 

Re: Current state of Xen microcode (Was: Re: uploading 3.16~rc5-1~exp1)

[Jan Beulich]

>>> On 04.08.14 at 16:07, <konrad.wilk@oracle.com> wrote:
> On Wed, Jul 23, 2014 at 03:59:37PM +0100, Jan Beulich wrote:
>> >>> On 15.07.14 at 16:59, <konrad.wilk@oracle.com> wrote:
>> > On Tue, Jul 15, 2014 at 09:53:32AM +0100, Ian Campbell wrote:
>> >> Adding xen-devel and some of the Linux maints,
>> >> 
>> >> On Mon, 2014-07-14 at 23:22 +0200, maximilian attems wrote:
>> >> > I will upload tomorrow Tuesday around 22h00 UT to experimental.
>> >> > 
>> >> > There are two TODOS concerning the not yet forwarded Debian patches:
>> >> > - cgroups
>> >> > - xen microcode
>> >> > 
>> >> > 
>> >> > I consider both not a blocker, but would be happy if Xen guys could
>> >> > have a look for what is needed.
>> >> 
>> >> The xen microcode patches which maks is referring to are these:
>> >> 
>> > 
> http://anonscm.debian.org/viewvc/kernel/dists/trunk/linux/debian/patches/feat 
> 
>> > ures/all/xen/
>> >> which are a forward port of Jeremy's old microcode_xen.ko driver.
>> > 
>> > They are also at my branch
>> > 
> http://git.kernel.org/cgit/linux/kernel/git/konrad/xen.git/log/?h=stable/mis 
>> > c
>> > 
>> > Hm, I should rebase them at some point.
>> >> 
>> >> I've not been keeping up on Xen x86 microcode stuff these days but I
>> >> think we don't need this any more with modern Xen since we can parse the
>> >> microcode blob off the front of the initrd, is that right?
>> > 
>> > Right. And best of it, the support for that is in dracut so
>> > it automatically can happen (thought you still need to add
>> > 'ucode=scan' in the /etc/default/grub.cfg in the GRUB_CMDLINE_XEN
>> > parameter) and also in /etc/dracut.conf add 'early_microcode=yes'.
>> 
>> Except that all this still doesn't take care of updating microcode at
>> runtime. Yet that should - like kexec - be implemented in the
>> respective tools such that no kernel involvement it required.
> 
> What are such tools?

Wasn't there a microcode_ctl tool/package?

> My recollection is that it is matter of
> sticking the files in /lib/firmware and then udev - will try
> at the detection of an CPU becoming online, do:
>  - load microcode module
>  - echo 1 > to the 'reload' sysfs parameter
> 
> Perhaps the solution is simple:
>  - write an xen userspace tool that will do this loading via
>    the hypercalls.
>  - plug said tool in the udev script that comes with xen.
>  - distros will install said udev scripts when they install Xen rpms?
> 
> That sounds too simple to be true. I must be missing something :-)

That would be an option too (namely if, say, the microcode_ctl tool
is considered deprecated/dead), and indeed can't be very difficult.

Jan

Re: Current state of Xen microcode (Was: Re: uploading 3.16~rc5-1~exp1)

[Konrad Rzeszutek Wilk]

On Mon, Aug 04, 2014 at 03:40:45PM +0100, Jan Beulich wrote:
> >>> On 04.08.14 at 16:07, <konrad.wilk@oracle.com> wrote:
> > On Wed, Jul 23, 2014 at 03:59:37PM +0100, Jan Beulich wrote:
> >> >>> On 15.07.14 at 16:59, <konrad.wilk@oracle.com> wrote:
> >> > On Tue, Jul 15, 2014 at 09:53:32AM +0100, Ian Campbell wrote:
> >> >> Adding xen-devel and some of the Linux maints,
> >> >> 
> >> >> On Mon, 2014-07-14 at 23:22 +0200, maximilian attems wrote:
> >> >> > I will upload tomorrow Tuesday around 22h00 UT to experimental.
> >> >> > 
> >> >> > There are two TODOS concerning the not yet forwarded Debian patches:
> >> >> > - cgroups
> >> >> > - xen microcode
> >> >> > 
> >> >> > 
> >> >> > I consider both not a blocker, but would be happy if Xen guys could
> >> >> > have a look for what is needed.
> >> >> 
> >> >> The xen microcode patches which maks is referring to are these:
> >> >> 
> >> > 
> > http://anonscm.debian.org/viewvc/kernel/dists/trunk/linux/debian/patches/feat 
> > 
> >> > ures/all/xen/
> >> >> which are a forward port of Jeremy's old microcode_xen.ko driver.
> >> > 
> >> > They are also at my branch
> >> > 
> > http://git.kernel.org/cgit/linux/kernel/git/konrad/xen.git/log/?h=stable/mis 
> >> > c
> >> > 
> >> > Hm, I should rebase them at some point.
> >> >> 
> >> >> I've not been keeping up on Xen x86 microcode stuff these days but I
> >> >> think we don't need this any more with modern Xen since we can parse the
> >> >> microcode blob off the front of the initrd, is that right?
> >> > 
> >> > Right. And best of it, the support for that is in dracut so
> >> > it automatically can happen (thought you still need to add
> >> > 'ucode=scan' in the /etc/default/grub.cfg in the GRUB_CMDLINE_XEN
> >> > parameter) and also in /etc/dracut.conf add 'early_microcode=yes'.
> >> 
> >> Except that all this still doesn't take care of updating microcode at
> >> runtime. Yet that should - like kexec - be implemented in the
> >> respective tools such that no kernel involvement it required.
> > 
> > What are such tools?
> 
> Wasn't there a microcode_ctl tool/package?

There was but it is obsolete:

***************************************************************************
>>> What it does
***************************************************************************
Deploy an Intel and AMD microcode. This tool is obsolete and the microcode
is the subject to be distributed via kernel-firmware, however Intel still
does not supply the microcode in a form consumable by the Linux's microcode

> 
> > My recollection is that it is matter of
> > sticking the files in /lib/firmware and then udev - will try
> > at the detection of an CPU becoming online, do:
> >  - load microcode module
> >  - echo 1 > to the 'reload' sysfs parameter
> > 
> > Perhaps the solution is simple:
> >  - write an xen userspace tool that will do this loading via
> >    the hypercalls.
> >  - plug said tool in the udev script that comes with xen.
> >  - distros will install said udev scripts when they install Xen rpms?
> > 
> > That sounds too simple to be true. I must be missing something :-)
> 
> That would be an option too (namely if, say, the microcode_ctl tool
> is considered deprecated/dead), and indeed can't be very difficult.

Vacation does wonders for ones brain! I shall put it on the TODO list.
thank you!
> 
> Jan
>