[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Linux 3.11 and the future...
On Thu, Jun 06, 2013 at 02:14:45PM +0100, Jan Beulich wrote: > >>> On 06.06.13 at 15:07, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> > >>> wrote: > > On Thu, Jun 06, 2013 at 08:38:57AM +0100, Jan Beulich wrote: > >> >>> On 05.06.13 at 22:19, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> > >> >>> wrote: > >> > b) microcode update. One needs to cherry-pick > >> > xen: add CPU microcode update driver > >> > x86/microcode: check proper return code. > >> > microcode_xen: Add support for AMD family >= 15h > >> > > >> > The one solution is to use the piggyback on early microcode loading > >> > that the Linux kernel is doing. Needs implementation in the > >> > hypervisor. > >> > >> What hypervisor side solution apart from the existing ucode > >> updating during early boot are you thinking of here? > > > > Copy from the > > http://wiki.xen.org/wiki/GSoC_2013#Microcode_uploader_implementation_in_Xen_ > > > > hypervisor > > > > " > > Intel is working on early implementation where the microcode binary > > would be appended to the initrd image. The kernel would scan for the > > appropriate magic constant > > (http://thread.gmane.org/gmane.linux.kernel/1413384; looks for > > "kernel/x86/microcode/GenuineIntel.bin") and load the microcode very > > early. This is all done for the Linux kernel code, but we currently do > > not that in the Xen hypervisor. > > The scope of the work can be split up in > > a) just do the extraction of microcode from the initial ramdisk binary (aka > > initrd) and apply it. This can be done during the parsing of the dom0 > > initial ramdisk. The hypervisor already has the functionality to apply a > > microcode from the multiboot targets. This would add code to parse the > > initrd image > > b) do it during very early bootup - which is why the early microcode work > > started - to deal with CPUs which don't expose certain CPUID flags > > because they need a microcode update. This part of work is much more > > difficult - as it would involve working only with early bootup > > pagetables. This being done _before_ the Xen hypervisor sets its own > > pagetables - as some of the fixes that the microcode has, can be for the > > CPU to be able to do PSE properly. > > " > > > > The a) solution was what I had in mind. > > Imo this is not a viable option - we shouldn't start peeking into the > second module (which Linux uses as initrd, but which other OSes > may use for other purposes) - so far this is just a binary blob to the > hypervisor. > I was under the impression that the code you introduced for microcode loading was doing that exactly. Granted it would only peek if told to. Perhaps that code can be expanded to scan the blob for cpio image of microcode in whatever it was told to look at? Dracut could pass in the extra argument to hypervisor to tell it to scan the initrd image. > Jan > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |