[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] How many patches are missing in upstream Linux?
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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |