Linux 3.11 and the future...

Linux 3.11 and the future...

[Konrad Rzeszutek Wilk]

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?

Re: Linux 3.11 and the future...

[Jan Beulich]

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

Re: Linux 3.11 and the future...

[Konrad Rzeszutek Wilk]

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.

Re: Linux 3.11 and the future...

[Jan Beulich]

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

Re: Linux 3.11 and the future...

[Konrad Rzeszutek Wilk]

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
> 

Re: Linux 3.11 and the future...

[Jan Beulich]

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

Re: Linux 3.11 and the future...

[Konrad Rzeszutek Wilk]

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
>