There are couple of different patches that have not been reworked
or upstream properly for v3.11. The ones that I am aware of are:
a) PAT. For that to work right now properly one needs to revert
two git commits: c79c49826270b8b0061b2fca840fc3f013c8a78a
8eaffa67b43e99ae581622c5133e20b0f48bcef1 and cherrypick
x86/cpa: Use pte_attrs instead of pte_flags on CPA/set_p.._wb/wc operations.
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.
c) efi. One needs to use the patches posted by Eric Shelton
which are back-ports of work done by Tang Liang
Daniel Kiper is taking a look at in the summer and try
to do it differently.
d). multi-MSI. Jan posted a patch but that needs to be reworked
in pvops kernel.
e). VCPUOP_register_vcpu_time_memory_area
There was a post in the eons ago to use this under Xen...
There are also bugs, but lets ignore those in this email.
The ones that are now off the list are:
- kexec. This can be now done via a new hypercall. Work is in progress
and should be in Xen 4.4.
- acpi s3. Patches are in v3.11 (Rafael''s linux-next branch).
Ben Guthro got Ack from hpa for it.
Am I missing any?
>>> On 05.06.13 at 22:19, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> 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? Jan
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@oracle.com> 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.
>>> On 06.06.13 at 15:07, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> 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@oracle.com> 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. Jan
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@oracle.com> 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@oracle.com> 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 >
>>> On 07.06.13 at 15:58, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote: > On Thu, Jun 06, 2013 at 02:14:45PM +0100, Jan Beulich wrote: >> 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?No, this is a separate (usually third) grub module, containing just the raw microcode data (in the same format that otherwise would get passed down from Dom0 via hypercall). Jan
On Fri, Jun 07, 2013 at 04:43:52PM +0100, Jan Beulich wrote:> >>> On 07.06.13 at 15:58, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote: > > On Thu, Jun 06, 2013 at 02:14:45PM +0100, Jan Beulich wrote: > >> 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? > > No, this is a separate (usually third) grub module, containing just > the raw microcode data (in the same format that otherwise would > get passed down from Dom0 via hypercall).Correct. What I was thinking would be beneficial is extend the code such that if the user wishes - it could scan one of the grub modules for a signature and if so, extract the relevant microcode from the cpio image. Then apply it.> > Jan >