Re: How many patches are missing in upstream Linux?

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

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