Re: [Xen-devel] Current state of Xen microcode (Was: Re: uploading 3.16~rc5-1~exp1)
On Wed, Jul 23, 2014 at 03:59:37PM +0100, Jan Beulich wrote: On 15.07.14 at 16:59, konrad.w...@oracle.com wrote: On Tue, Jul 15, 2014 at 09:53:32AM +0100, Ian Campbell wrote: Adding xen-devel and some of the Linux maints, On Mon, 2014-07-14 at 23:22 +0200, maximilian attems wrote: I will upload tomorrow Tuesday around 22h00 UT to experimental. There are two TODOS concerning the not yet forwarded Debian patches: - cgroups - xen microcode I consider both not a blocker, but would be happy if Xen guys could have a look for what is needed. The xen microcode patches which maks is referring to are these: http://anonscm.debian.org/viewvc/kernel/dists/trunk/linux/debian/patches/feat ures/all/xen/ which are a forward port of Jeremy's old microcode_xen.ko driver. They are also at my branch http://git.kernel.org/cgit/linux/kernel/git/konrad/xen.git/log/?h=stable/mis c Hm, I should rebase them at some point. I've not been keeping up on Xen x86 microcode stuff these days but I think we don't need this any more with modern Xen since we can parse the microcode blob off the front of the initrd, is that right? Right. And best of it, the support for that is in dracut so it automatically can happen (thought you still need to add 'ucode=scan' in the /etc/default/grub.cfg in the GRUB_CMDLINE_XEN parameter) and also in /etc/dracut.conf add 'early_microcode=yes'. Except that all this still doesn't take care of updating microcode at runtime. Yet that should - like kexec - be implemented in the respective tools such that no kernel involvement it required. What are such tools? My recollection is that it is matter of sticking the files in /lib/firmware and then udev - will try at the detection of an CPU becoming online, do: - load microcode module - echo 1 to the 'reload' sysfs parameter Perhaps the solution is simple: - write an xen userspace tool that will do this loading via the hypercalls. - plug said tool in the udev script that comes with xen. - distros will install said udev scripts when they install Xen rpms? That sounds too simple to be true. I must be missing something :-) Jan -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140804140730.gd18...@laptop.dumpdata.com
Re: [Xen-devel] Current state of Xen microcode (Was: Re: uploading 3.16~rc5-1~exp1)
On 04.08.14 at 16:07, konrad.w...@oracle.com wrote: On Wed, Jul 23, 2014 at 03:59:37PM +0100, Jan Beulich wrote: On 15.07.14 at 16:59, konrad.w...@oracle.com wrote: On Tue, Jul 15, 2014 at 09:53:32AM +0100, Ian Campbell wrote: Adding xen-devel and some of the Linux maints, On Mon, 2014-07-14 at 23:22 +0200, maximilian attems wrote: I will upload tomorrow Tuesday around 22h00 UT to experimental. There are two TODOS concerning the not yet forwarded Debian patches: - cgroups - xen microcode I consider both not a blocker, but would be happy if Xen guys could have a look for what is needed. The xen microcode patches which maks is referring to are these: http://anonscm.debian.org/viewvc/kernel/dists/trunk/linux/debian/patches/feat ures/all/xen/ which are a forward port of Jeremy's old microcode_xen.ko driver. They are also at my branch http://git.kernel.org/cgit/linux/kernel/git/konrad/xen.git/log/?h=stable/mis c Hm, I should rebase them at some point. I've not been keeping up on Xen x86 microcode stuff these days but I think we don't need this any more with modern Xen since we can parse the microcode blob off the front of the initrd, is that right? Right. And best of it, the support for that is in dracut so it automatically can happen (thought you still need to add 'ucode=scan' in the /etc/default/grub.cfg in the GRUB_CMDLINE_XEN parameter) and also in /etc/dracut.conf add 'early_microcode=yes'. Except that all this still doesn't take care of updating microcode at runtime. Yet that should - like kexec - be implemented in the respective tools such that no kernel involvement it required. What are such tools? Wasn't there a microcode_ctl tool/package? My recollection is that it is matter of sticking the files in /lib/firmware and then udev - will try at the detection of an CPU becoming online, do: - load microcode module - echo 1 to the 'reload' sysfs parameter Perhaps the solution is simple: - write an xen userspace tool that will do this loading via the hypercalls. - plug said tool in the udev script that comes with xen. - distros will install said udev scripts when they install Xen rpms? That sounds too simple to be true. I must be missing something :-) That would be an option too (namely if, say, the microcode_ctl tool is considered deprecated/dead), and indeed can't be very difficult. Jan -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53dfb78d027800029...@mail.emea.novell.com
Re: [Xen-devel] Current state of Xen microcode (Was: Re: uploading 3.16~rc5-1~exp1)
On Mon, Aug 04, 2014 at 03:40:45PM +0100, Jan Beulich wrote: On 04.08.14 at 16:07, konrad.w...@oracle.com wrote: On Wed, Jul 23, 2014 at 03:59:37PM +0100, Jan Beulich wrote: On 15.07.14 at 16:59, konrad.w...@oracle.com wrote: On Tue, Jul 15, 2014 at 09:53:32AM +0100, Ian Campbell wrote: Adding xen-devel and some of the Linux maints, On Mon, 2014-07-14 at 23:22 +0200, maximilian attems wrote: I will upload tomorrow Tuesday around 22h00 UT to experimental. There are two TODOS concerning the not yet forwarded Debian patches: - cgroups - xen microcode I consider both not a blocker, but would be happy if Xen guys could have a look for what is needed. The xen microcode patches which maks is referring to are these: http://anonscm.debian.org/viewvc/kernel/dists/trunk/linux/debian/patches/feat ures/all/xen/ which are a forward port of Jeremy's old microcode_xen.ko driver. They are also at my branch http://git.kernel.org/cgit/linux/kernel/git/konrad/xen.git/log/?h=stable/mis c Hm, I should rebase them at some point. I've not been keeping up on Xen x86 microcode stuff these days but I think we don't need this any more with modern Xen since we can parse the microcode blob off the front of the initrd, is that right? Right. And best of it, the support for that is in dracut so it automatically can happen (thought you still need to add 'ucode=scan' in the /etc/default/grub.cfg in the GRUB_CMDLINE_XEN parameter) and also in /etc/dracut.conf add 'early_microcode=yes'. Except that all this still doesn't take care of updating microcode at runtime. Yet that should - like kexec - be implemented in the respective tools such that no kernel involvement it required. What are such tools? Wasn't there a microcode_ctl tool/package? There was but it is obsolete: *** What it does *** Deploy an Intel and AMD microcode. This tool is obsolete and the microcode is the subject to be distributed via kernel-firmware, however Intel still does not supply the microcode in a form consumable by the Linux's microcode My recollection is that it is matter of sticking the files in /lib/firmware and then udev - will try at the detection of an CPU becoming online, do: - load microcode module - echo 1 to the 'reload' sysfs parameter Perhaps the solution is simple: - write an xen userspace tool that will do this loading via the hypercalls. - plug said tool in the udev script that comes with xen. - distros will install said udev scripts when they install Xen rpms? That sounds too simple to be true. I must be missing something :-) That would be an option too (namely if, say, the microcode_ctl tool is considered deprecated/dead), and indeed can't be very difficult. Vacation does wonders for ones brain! I shall put it on the TODO list. thank you! Jan -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140804150248.gd19...@laptop.dumpdata.com
Re: [Xen-devel] Current state of Xen microcode (Was: Re: uploading 3.16~rc5-1~exp1)
On 15.07.14 at 16:59, konrad.w...@oracle.com wrote: On Tue, Jul 15, 2014 at 09:53:32AM +0100, Ian Campbell wrote: Adding xen-devel and some of the Linux maints, On Mon, 2014-07-14 at 23:22 +0200, maximilian attems wrote: I will upload tomorrow Tuesday around 22h00 UT to experimental. There are two TODOS concerning the not yet forwarded Debian patches: - cgroups - xen microcode I consider both not a blocker, but would be happy if Xen guys could have a look for what is needed. The xen microcode patches which maks is referring to are these: http://anonscm.debian.org/viewvc/kernel/dists/trunk/linux/debian/patches/feat ures/all/xen/ which are a forward port of Jeremy's old microcode_xen.ko driver. They are also at my branch http://git.kernel.org/cgit/linux/kernel/git/konrad/xen.git/log/?h=stable/mis c Hm, I should rebase them at some point. I've not been keeping up on Xen x86 microcode stuff these days but I think we don't need this any more with modern Xen since we can parse the microcode blob off the front of the initrd, is that right? Right. And best of it, the support for that is in dracut so it automatically can happen (thought you still need to add 'ucode=scan' in the /etc/default/grub.cfg in the GRUB_CMDLINE_XEN parameter) and also in /etc/dracut.conf add 'early_microcode=yes'. Except that all this still doesn't take care of updating microcode at runtime. Yet that should - like kexec - be implemented in the respective tools such that no kernel involvement it required. Jan -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53cfe9f9027800025...@mail.emea.novell.com
Current state of Xen microcode (Was: Re: uploading 3.16~rc5-1~exp1)
Adding xen-devel and some of the Linux maints, On Mon, 2014-07-14 at 23:22 +0200, maximilian attems wrote: I will upload tomorrow Tuesday around 22h00 UT to experimental. There are two TODOS concerning the not yet forwarded Debian patches: - cgroups - xen microcode I consider both not a blocker, but would be happy if Xen guys could have a look for what is needed. The xen microcode patches which maks is referring to are these: http://anonscm.debian.org/viewvc/kernel/dists/trunk/linux/debian/patches/features/all/xen/ which are a forward port of Jeremy's old microcode_xen.ko driver. I've not been keeping up on Xen x86 microcode stuff these days but I think we don't need this any more with modern Xen since we can parse the microcode blob off the front of the initrd, is that right? (this is predicated on Xen 4.4 hitting unstable, which is underway) Thanks, Ian. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1405414412.1389.5.ca...@kazak.uk.xensource.com
Re: [Xen-devel] Current state of Xen microcode (Was: Re: uploading 3.16~rc5-1~exp1)
On Tue, 2014-07-15 at 10:59 -0400, Konrad Rzeszutek Wilk wrote: On Tue, Jul 15, 2014 at 09:53:32AM +0100, Ian Campbell wrote: Adding xen-devel and some of the Linux maints, On Mon, 2014-07-14 at 23:22 +0200, maximilian attems wrote: I will upload tomorrow Tuesday around 22h00 UT to experimental. There are two TODOS concerning the not yet forwarded Debian patches: - cgroups - xen microcode I consider both not a blocker, but would be happy if Xen guys could have a look for what is needed. The xen microcode patches which maks is referring to are these: http://anonscm.debian.org/viewvc/kernel/dists/trunk/linux/debian/patches/features/all/xen/ which are a forward port of Jeremy's old microcode_xen.ko driver. They are also at my branch http://git.kernel.org/cgit/linux/kernel/git/konrad/xen.git/log/?h=stable/misc Hm, I should rebase them at some point. I've not been keeping up on Xen x86 microcode stuff these days but I think we don't need this any more with modern Xen since we can parse the microcode blob off the front of the initrd, is that right? Right. And best of it, the support for that is in dracut so it automatically can happen (thought you still need to add 'ucode=scan' in the /etc/default/grub.cfg in the GRUB_CMDLINE_XEN parameter) and also in /etc/dracut.conf add 'early_microcode=yes'. Hrm, I thought it was transparent. Debian doesn't use dracut, it uses initramfs-tools. So perhaps there is some work to be done here. I understand ucode=scan, but what does the dracut option do? (this is predicated on Xen 4.4 hitting unstable, which is underway) unstable == Debian unstable? Yes. Ian. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1405436760.28874.1.ca...@kazak.uk.xensource.com
Re: [Xen-devel] Current state of Xen microcode (Was: Re: uploading 3.16~rc5-1~exp1)
On Tue, 2014-07-15 at 11:35 -0400, Konrad Rzeszutek Wilk wrote: On Tue, Jul 15, 2014 at 04:06:00PM +0100, Ian Campbell wrote: On Tue, 2014-07-15 at 10:59 -0400, Konrad Rzeszutek Wilk wrote: On Tue, Jul 15, 2014 at 09:53:32AM +0100, Ian Campbell wrote: Adding xen-devel and some of the Linux maints, On Mon, 2014-07-14 at 23:22 +0200, maximilian attems wrote: I will upload tomorrow Tuesday around 22h00 UT to experimental. There are two TODOS concerning the not yet forwarded Debian patches: - cgroups - xen microcode I consider both not a blocker, but would be happy if Xen guys could have a look for what is needed. The xen microcode patches which maks is referring to are these: http://anonscm.debian.org/viewvc/kernel/dists/trunk/linux/debian/patches/features/all/xen/ which are a forward port of Jeremy's old microcode_xen.ko driver. They are also at my branch http://git.kernel.org/cgit/linux/kernel/git/konrad/xen.git/log/?h=stable/misc Hm, I should rebase them at some point. I've not been keeping up on Xen x86 microcode stuff these days but I think we don't need this any more with modern Xen since we can parse the microcode blob off the front of the initrd, is that right? Right. And best of it, the support for that is in dracut so it automatically can happen (thought you still need to add 'ucode=scan' in the /etc/default/grub.cfg in the GRUB_CMDLINE_XEN parameter) and also in /etc/dracut.conf add 'early_microcode=yes'. Hrm, I thought it was transparent. Debian doesn't use dracut, it uses initramfs-tools. So perhaps there is some work to be done here. I understand ucode=scan, but what does the dracut option do? Packages the blobs and sticks them to the initramfs. OK. I think 'initframfs-tools' will need some code there. It already does the right thing automatically if the appropriate microcode package is installed, so no need for an option. So all which is needed is the ucode=scan I guess. Ian. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1405438981.28874.13.ca...@kazak.uk.xensource.com
Re: Current state of Xen microcode (Was: Re: uploading 3.16~rc5-1~exp1)
On Tue, Jul 15, 2014 at 09:53:32AM +0100, Ian Campbell wrote: Adding xen-devel and some of the Linux maints, On Mon, 2014-07-14 at 23:22 +0200, maximilian attems wrote: I will upload tomorrow Tuesday around 22h00 UT to experimental. There are two TODOS concerning the not yet forwarded Debian patches: - cgroups - xen microcode I consider both not a blocker, but would be happy if Xen guys could have a look for what is needed. The xen microcode patches which maks is referring to are these: http://anonscm.debian.org/viewvc/kernel/dists/trunk/linux/debian/patches/features/all/xen/ which are a forward port of Jeremy's old microcode_xen.ko driver. They are also at my branch http://git.kernel.org/cgit/linux/kernel/git/konrad/xen.git/log/?h=stable/misc Hm, I should rebase them at some point. I've not been keeping up on Xen x86 microcode stuff these days but I think we don't need this any more with modern Xen since we can parse the microcode blob off the front of the initrd, is that right? Right. And best of it, the support for that is in dracut so it automatically can happen (thought you still need to add 'ucode=scan' in the /etc/default/grub.cfg in the GRUB_CMDLINE_XEN parameter) and also in /etc/dracut.conf add 'early_microcode=yes'. (this is predicated on Xen 4.4 hitting unstable, which is underway) unstable == Debian unstable? Thanks, Ian. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140715145934.gm3...@laptop.dumpdata.com
Re: [Xen-devel] Current state of Xen microcode (Was: Re: uploading 3.16~rc5-1~exp1)
On Tue, Jul 15, 2014 at 04:06:00PM +0100, Ian Campbell wrote: On Tue, 2014-07-15 at 10:59 -0400, Konrad Rzeszutek Wilk wrote: On Tue, Jul 15, 2014 at 09:53:32AM +0100, Ian Campbell wrote: Adding xen-devel and some of the Linux maints, On Mon, 2014-07-14 at 23:22 +0200, maximilian attems wrote: I will upload tomorrow Tuesday around 22h00 UT to experimental. There are two TODOS concerning the not yet forwarded Debian patches: - cgroups - xen microcode I consider both not a blocker, but would be happy if Xen guys could have a look for what is needed. The xen microcode patches which maks is referring to are these: http://anonscm.debian.org/viewvc/kernel/dists/trunk/linux/debian/patches/features/all/xen/ which are a forward port of Jeremy's old microcode_xen.ko driver. They are also at my branch http://git.kernel.org/cgit/linux/kernel/git/konrad/xen.git/log/?h=stable/misc Hm, I should rebase them at some point. I've not been keeping up on Xen x86 microcode stuff these days but I think we don't need this any more with modern Xen since we can parse the microcode blob off the front of the initrd, is that right? Right. And best of it, the support for that is in dracut so it automatically can happen (thought you still need to add 'ucode=scan' in the /etc/default/grub.cfg in the GRUB_CMDLINE_XEN parameter) and also in /etc/dracut.conf add 'early_microcode=yes'. Hrm, I thought it was transparent. Debian doesn't use dracut, it uses initramfs-tools. So perhaps there is some work to be done here. I understand ucode=scan, but what does the dracut option do? Packages the blobs and sticks them to the initramfs. I think 'initframfs-tools' will need some code there. Here is what I did in dracut: http://git.kernel.org/cgit/boot/dracut/dracut.git/commit/?id=5f2c30d9bcd614d546d5c55c6897e33f88b9ab90 http://git.kernel.org/cgit/boot/dracut/dracut.git/commit/?id=b5b608e44ade93bee54d274f5edc6aad6dc45288 http://git.kernel.org/cgit/boot/dracut/dracut.git/commit/?id=d8b04dc1840047a7533d19f577f30f19d42e2d33 (this is predicated on Xen 4.4 hitting unstable, which is underway) unstable == Debian unstable? Yes. Ian. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140715153500.gw3...@laptop.dumpdata.com
Re: [Xen-devel] Current state of Xen microcode (Was: Re: uploading 3.16~rc5-1~exp1)
On Tue, 2014-07-15 at 11:35 -0400, Konrad Rzeszutek Wilk wrote: On Tue, Jul 15, 2014 at 04:06:00PM +0100, Ian Campbell wrote: On Tue, 2014-07-15 at 10:59 -0400, Konrad Rzeszutek Wilk wrote: On Tue, Jul 15, 2014 at 09:53:32AM +0100, Ian Campbell wrote: Adding xen-devel and some of the Linux maints, On Mon, 2014-07-14 at 23:22 +0200, maximilian attems wrote: I will upload tomorrow Tuesday around 22h00 UT to experimental. There are two TODOS concerning the not yet forwarded Debian patches: - cgroups - xen microcode I consider both not a blocker, but would be happy if Xen guys could have a look for what is needed. The xen microcode patches which maks is referring to are these: http://anonscm.debian.org/viewvc/kernel/dists/trunk/linux/debian/patches/features/all/xen/ which are a forward port of Jeremy's old microcode_xen.ko driver. They are also at my branch http://git.kernel.org/cgit/linux/kernel/git/konrad/xen.git/log/?h=stable/misc Hm, I should rebase them at some point. I've not been keeping up on Xen x86 microcode stuff these days but I think we don't need this any more with modern Xen since we can parse the microcode blob off the front of the initrd, is that right? Right. And best of it, the support for that is in dracut so it automatically can happen (thought you still need to add 'ucode=scan' in the /etc/default/grub.cfg in the GRUB_CMDLINE_XEN parameter) and also in /etc/dracut.conf add 'early_microcode=yes'. Hrm, I thought it was transparent. Debian doesn't use dracut, it uses initramfs-tools. So perhaps there is some work to be done here. I understand ucode=scan, but what does the dracut option do? Packages the blobs and sticks them to the initramfs. I think 'initframfs-tools' will need some code there. [...] initramfs-tools can already prepend microcode in the way Linux expects. I assume Xen supports the same format (it's a little weird for it to be parsing the dom0 initrd, but OK...). But we're presumably missing the GRUB integration to get 'ucode=scan' added automatically. Ben. -- Ben Hutchings Hoare's Law of Large Problems: Inside every large problem is a small problem struggling to get out. signature.asc Description: This is a digitally signed message part
Re: [Xen-devel] Current state of Xen microcode (Was: Re: uploading 3.16~rc5-1~exp1)
On Tue, Jul 15, 2014 at 06:53:04PM +0100, Ben Hutchings wrote: On Tue, 2014-07-15 at 11:35 -0400, Konrad Rzeszutek Wilk wrote: On Tue, Jul 15, 2014 at 04:06:00PM +0100, Ian Campbell wrote: On Tue, 2014-07-15 at 10:59 -0400, Konrad Rzeszutek Wilk wrote: On Tue, Jul 15, 2014 at 09:53:32AM +0100, Ian Campbell wrote: Adding xen-devel and some of the Linux maints, On Mon, 2014-07-14 at 23:22 +0200, maximilian attems wrote: I will upload tomorrow Tuesday around 22h00 UT to experimental. There are two TODOS concerning the not yet forwarded Debian patches: - cgroups - xen microcode I consider both not a blocker, but would be happy if Xen guys could have a look for what is needed. The xen microcode patches which maks is referring to are these: http://anonscm.debian.org/viewvc/kernel/dists/trunk/linux/debian/patches/features/all/xen/ which are a forward port of Jeremy's old microcode_xen.ko driver. They are also at my branch http://git.kernel.org/cgit/linux/kernel/git/konrad/xen.git/log/?h=stable/misc Hm, I should rebase them at some point. I've not been keeping up on Xen x86 microcode stuff these days but I think we don't need this any more with modern Xen since we can parse the microcode blob off the front of the initrd, is that right? Right. And best of it, the support for that is in dracut so it automatically can happen (thought you still need to add 'ucode=scan' in the /etc/default/grub.cfg in the GRUB_CMDLINE_XEN parameter) and also in /etc/dracut.conf add 'early_microcode=yes'. Hrm, I thought it was transparent. Debian doesn't use dracut, it uses initramfs-tools. So perhaps there is some work to be done here. I understand ucode=scan, but what does the dracut option do? Packages the blobs and sticks them to the initramfs. I think 'initframfs-tools' will need some code there. [...] initramfs-tools can already prepend microcode in the way Linux expects. I assume Xen supports the same format (it's a little weird for it to be parsing the dom0 initrd, but OK...). But we're presumably missing the It scans all of the binary blobs that are attached looking for the proper cpio signature. So you could do it as a seperate cpio binary. Or a binary blob (cat /lib/firmware/*ucode/* /boot/multiboot.bin) and the 'multiboot.bin' can be part of the multiboot stanza: module /multiboot.bin And you add 'ucode=-1' for it to take the last module and use that as its source of microcode code. However, the 'ucode=scan' is more in line with what Linux has with the early microcode loading so you are better of using that and it will be less work. GRUB integration to get 'ucode=scan' added automatically. nods Ben. -- Ben Hutchings Hoare's Law of Large Problems: Inside every large problem is a small problem struggling to get out. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140715180821.gd2...@laptop.dumpdata.com
