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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 04.08.14 at 16:07, <konrad.wilk@xxxxxxxxxx> wrote:
> On Wed, Jul 23, 2014 at 03:59:37PM +0100, Jan Beulich wrote:
>> >>> On 15.07.14 at 16:59, <konrad.wilk@xxxxxxxxxx> 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


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