Initial support for ARM64
v4 cover Initial support for ARM64
The following adds support for testing on arm64 systems.
Since arm64 was only added in Debian Jessie this requires Wei's "Debian Jessie patches" as a base line, which are currently in osstest. This is therefore based on those, specifically 6e37f849f4b0.
I've addressed the issues raised last time and dropped the VMEMMMAP hack since it is now understood. I retained acks on the two mg-* changes despite folding everything into mgi-common as well as the "die on ! jessie" change to the UEFI boot order bodge, since all that seemed minor enough, I hope that's ok:
AM mg-*: Add mgi-common with fetch and fail helpers
AM mg-*: Make Debian package fetching common in mgi-common
AM Introduce mg-pxe-loader-update
A Debian: Preseed a EFI system partition during host install
A ts-host-install: Split initrd out of @installcmdline
A ts-host-install: split the "di" from the "host" command line
A Refactor pxelinux configuration
AM ts-host-install: Support UEFI PXE boot using grub.efi
A Enable chain loading to local disk for UEFI PXE systems.
A Add arm64 build and test jobs
A ts-kernel-build: Additional kernel options for Mustang
A ts-kernel-build: Enable CONFIG_EFI_VARS
A ts-host-install: Set dtbs in the non-special kernel case too.
AM Debian: Do not add Debian to UEFI boot order on install
A standalone: Prefer ./local-config to $HOME/.xen-osstest/config
A Debian: grub2: Log full line range of menuentry and submenu entries
A Debian: grub2: Use GRUB_CMDLINE_LINUX_XEN_REPLACE(_DEFAULT)
A Collect xen.efi into xendist and install in appropriate place
A Debian: Ignore xen-syms entries in grub.cfg.
A Debian: Collect kernel command line from grub.cfg
M Debian: Arrange to be able to chainload a xen.efi from grub2
A -- Acked
M -- Modified
That's all bar the final patch acked I think. However we haven't yet got any hardware and this is dependent on a switch to Jessie for tests. I support we don't want to just take this directly and let the tests be failing ts-host-allocate since that will just add noise to the reports. I could put this to one side and rebase once h/w shows up, or I could tweak mfi-common to omit arm64 from (BUILD|TEST)_ARCHES for now and we could apply it.
Ian.
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xen.org/xen-devel
PATCH v4 1/21 mg-*: Add mgi-common with fetch and fail helpers
Taken from both mg-cpu-microcode-update and mg-debian-installer-update
---
v3: New patch
--- mg-cpu-microcode-update | 3 ++- mg-debian-installer-update | 8 +------- mgi-common | 26 ++++++++++++++++++++++++++ 3 files changed, 29 insertions(+), 8 deletions(-) create mode 100644 mgi-common
mg-cpu-microcode-update +2 -1
@@ -3,6 +3,7 @@ set -e . cri-getconfig +. mgi-common # iucode_tool is in /usr/sbin, see #788459. export PATH="/usr/local/sbin:$PATH:/sbin:/usr/sbin"
@@ -41,7 +42,7 @@ INTEL_TGZ='http://downloadmirror.intel.com/24661/eng/microcode-20150121.tgz' mkdir intel-ucode echo >&2 "Fetching Intel ucode" -curl -s $INTEL_TGZ > intel-ucode/microcode.tgz +fetch $INTEL_TGZ > intel-ucode/microcode.tgz tar -C intel-ucode -xaf intel-ucode/microcode.tgz microcode.dat
mg-debian-installer-update +1 -7
@@ -22,21 +22,15 @@ set -e . cri-getconfig +. mgi-common suite=$1 arch=$2 packages="$3" -fail () { echo >&2 "$0: $1"; exit 1; } - site=http://ftp.debian.org/debian/ sbase=$site/dists/$suite -fetch () { - # no-cache due to intercepting proxies messing things up. - curl -s -H 'Pragma: no-cache' $1 -} - case ${suite}_${arch} in lenny_armhf|squeeze_armhf|lenny_arm64|squeeze_arm64|wheezy_arm64) # No such thing.
mgi-common new file +26 -0
@@ -0,0 +1,26 @@ +# -*- bash -*- + +# Helpers for mg-* +# +# This is part of "osstest", an automated testing framework for Xen. +# Copyright (C) 2015 Citrix Inc. +# +# This program is free software: you can redistribute it and/or modify +# it under the terms of the GNU Affero General Public License as published by +# the Free Software Foundation, either version 3 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU Affero General Public License for more details. +# +# You should have received a copy of the GNU Affero General Public License +# along with this program. If not, see <http://www.gnu.org/licenses/>. + +fail () { echo >&2 "$0: $1"; exit 1; } + +fetch () { + # no-cache due to intercepting proxies messing things up. + curl -s -H 'Pragma: no-cache' $1 +}
Signature · 1 line
2.1.4
PATCH v4 2/21 mg-*: Make Debian package fetching common in mgi-common
In reply to Ian CampbellThis pattern appears several times in mg-debian-installer-update and I'm about to add another script which uses it.
The centralised version always does "sort -n -r | head -n" to pick out only the newest version, which only some of the open coded sites did.
Likewise the centralised version checks that $pkgfile is non-empty, unlike some of the open coded sites.
---
v4: Fold into mgi-common instead
v3: New patch
--- mg-debian-installer-update | 33 ++++++++------------------------- mgi-common | 19 +++++++++++++++++++ 2 files changed, 27 insertions(+), 25 deletions(-)
mg-debian-installer-update +8 -25
@@ -59,8 +59,6 @@ case ${suite}_${arch} in ;; esac -pfile=$sbase/non-free/binary-$arch/Packages.gz - dstroot=`getconfig TftpPath`/`getconfig TftpDiBase`/ date=`date +%Y-%m-%d`-$suite dst=$arch/$date
@@ -85,16 +83,13 @@ if [ "x$dtbs" != "x" ] ; then gzip -9nf dtbs.tar fi +pfile=$sbase/non-free/binary-$arch/Packages.gz + fetch $pfile >Packages.gz for p in $packages; do - set +e echo >&2 "collecting $p" - pkgfile=`zcat Packages.gz | grep-dctrl -PX $p -nsFilename` - rc=$? - set -e - if [ $rc != 0 ]; then fail "package $p not found"; fi - fetch "$site/$pkgfile" >$p.deb + fetch_debian_package "$site" Packages.gz -PX $p >$p.deb rm -rf x dpkg-deb -x $p.deb x cd x; pax -x sv4cpio -s '%lib%/lib%' -w -M norm lib >../cpio; cd ..
@@ -117,30 +112,18 @@ if [ x$bpok != x ]; then if [ x$need_initramfs = xy ]; then # Newer kernel often needs a newer initramfs-tools. Make that - # available + # is available echo >&2 "collecting backports initramfs-tools" - pkgfile=`zcat Packages.gz \ - | grep-dctrl -PX initramfs-tools -nsFilename \ - | sort -n -r | head -n1` - rc=$? - set -e - if [ $rc -ne 0 ] || [ x$pkgfile = x ]; then - fail "initramfs-tools package not found"; - fi - fetch "$site/$pkgfile" >initramfs-tools.deb + fetch_debian_package $site Packages.gz -PX initramfs-tools \ + >initramfs-tools.deb fi set +e echo >&2 "collecting backports kernel" # Be careful to pickup the actual kernel package from the 'linux' # source and not a meta package from 'linux-latest' - pkgfile=`zcat Packages.gz | grep-dctrl -S linux \ - | grep-dctrl -Pe ^linux-image-.*-${bpok}$ -nsFilename \ - | sort -n -r | head -n1` - rc=$? - set -e - if [ $rc != 0 ]; then fail "backports kernel package not found"; fi - fetch "$site/$pkgfile" >backports.deb + fetch_debian_package $site Packages.gz -Pe ^linux-image-.*-${bpok}$ \ + >backports.deb dpkg-deb -x backports.deb x cp x/boot/vmlinuz-* linux.backports # The full set of modules is pretty large and not that
mgi-common +19 -0
@@ -24,3 +24,22 @@ fetch () { # no-cache due to intercepting proxies messing things up. curl -s -H 'Pragma: no-cache' $1 } + +# Arguments: <Base URL> <Packages.gz> <grep-dctrl arguments> +# +# nb: -nsFilename argument to grep-dctrl is supplied here +fetch_debian_package () { + local site=$1 ; shift 1 + local pgz=$1 ; shift 1 + + set +e + pkgfile=`zcat $pgz | grep-dctrl $@ -nsFilename | sort -n -r | head -n1` + rc=$? + set -e + + if [ $rc -ne 0 ] || [ x$pkgfile = x ]; then + fail "package matching $@ not found"; + fi + + fetch "$site/$pkgfile" +}
Signature · 1 line
2.1.4
PATCH v4 3/21 Introduce mg-pxe-loader-update
In reply to Ian CampbellThe story for PXE booting via UEFI (at least on arm64) is not so straightforward as with pxelinux on x86. There seems to no good bootloader to launch via UEFI+pxe, in fact all I could find was grub (syslinux, and by extension pxelinux.efi, is x86 only).
Add mg-pxe-loader-update modelled on mg-debian-installer-update which will download the necessary grub binaries and produce a grub image which can be used to pxe boot.
grub lacks the convenient ability to search for config file based on (substrings of) the MAC or IP address. So we arrange for the grub.cfg in TftpGrubBase to chain load another config file from TftpTmpDir/'$net_default_mac' where $net_default_mac is a grub variable which is substituted at boot time.
Actually using this requires that bootp/dhcp provide a next-file so UEFI knows what to boot (usually this would be pxelinux.0 which we can't use here). Locally we have configured this as $name/pxe.img, so we can use different loaders.
---
v4: Just mgi-common now that mgi-debian merged therein.
v3: Use mgi-common and mgi-debian
--- Osstest.pm | 3 ++ README | 4 ++- mg-pxe-loader-update | 84 ++++++++++++++++++++++++++++++++++++++++++++++++++++ production-config | 5 ++++ 4 files changed, 95 insertions(+), 1 deletion(-) create mode 100755 mg-pxe-loader-update
Osstest.pm +3 -0
@@ -200,6 +200,9 @@ sub readglobalconfig () { $c{TftpDiBase} ||= "$c{TftpPlayDir}debian-installer"; $c{TftpDiVersion} ||= 'current'; + $c{TftpGrubBase} ||= "$c{TftpPlayDir}grub"; + $c{TftpGrubVersion} ||= 'current'; + $c{WebspaceFile} ||= "$ENV{'HOME'}/public_html/"; $c{WebspaceUrl} ||= "http://$myfqdn/~$whoami/"; $c{WebspaceCommon} ||= 'osstest/';
README +3 -1
@@ -206,7 +206,9 @@ To run osstest in standalone mode: netcat chiark-utils-bin - - Optional: ipmitool + - Optional: + ipmitool -- for hosts which use IPMI for power control + grub-common -- for mg-pxe-loader-update - Write a config file ~/.xen-osstest/config
mg-pxe-loader-update new file +84 -0
84 lines not on this page · raw message
production-config +5 -0
@@ -82,12 +82,17 @@ TftpPxeTemplates %name%/pxelinux.cfg TftpPxeTemplatesReal pxelinux.cfg/%ipaddrhex% TftpPxeGroup osstest +# Update with ./mg-debian-installer-update(-all) TftpDiVersion 2015-06-23 # These should normally be the same. +# Update with ./mg-cpu-microcode-update MicrocodeUpdateAmd64 microcode.x86.2015-06-12.cpio MicrocodeUpdateI386 microcode.x86.2015-06-12.cpio +# Update with ./mg-pxe-loader-update +TftpGrubVersion XXXX-XX-XX + XenUsePath /usr/groups/xencore/systems/bin/xenuse XenUseUser osstest
Signature · 1 line
2.1.4
PATCH v4 4/21 Debian: Preseed a EFI system partition during host install
In reply to Ian CampbellAIUI the runes used will only result in an ESP if the system was booted via UEFI. IOW I don't think there should be any change for existing systems.
--- Osstest.pm | 1 + Osstest/Debian.pm | 6 ++++++ 2 files changed, 7 insertions(+)
Osstest.pm +1 -0
@@ -68,6 +68,7 @@ our %c = qw( TestHostKeypairPath id_rsa_osstest HostProp_GenEtherPrefixBase 5e:36:0e:f5 + HostDiskESP 300 HostDiskBoot 300 HostDiskRoot 10000 HostDiskSwap 2000
Osstest/Debian.pm +6 -0
@@ -987,6 +987,12 @@ d-i partman-basicmethods/method_only boolean false d-i partman-auto/expert_recipe string \\ boot-root :: \\ + $c{HostDiskESP} 60 $c{HostDiskESP} free \\ + \$iflabel{ gpt } \\ + reusemethod{ } \\ + method{ efi } \\ + format{ } \\ + . \\ $c{HostDiskBoot} 50 $c{HostDiskBoot} ext3 \\ \$primary{ } \$bootable{ } \\ method{ format } format{ } \\
Signature · 1 line
2.1.4
PATCH v4 5/21 ts-host-install: Split initrd out of @installcmdline
In reply to Ian CampbellOther bootloaders handle this with an explicit separate option rather than parsing it out of the command line as pxelinux does. Prepare for supporting these.
--- ts-host-install | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-)
ts-host-install +2 -4
@@ -265,9 +265,7 @@ END my $initrd= "$ho->{Tftp}{TmpDir}$ho->{Name}--initrd.gz"; system_checked("cat -- @initrds >$ho->{Tftp}{Path}$initrd"); - push @installcmdline, ("initrd=/$initrd", - "domain=$c{TestHostDomain}", - ); + push @installcmdline, "domain=$c{TestHostDomain}"; push @installcmdline, get_host_property($ho, "install-append $ho->{Suite}", ''), get_host_property($ho, "install-append $ho->{Suite} $r{arch}", '');
@@ -295,7 +293,7 @@ label overwrite menu label ^Overwrite menu default kernel $kernel - append $installcmdline + append initrd=/$initrd $installcmdline ipappend $ipappend $dtbs default overwrite
Signature · 1 line
2.1.4
PATCH v4 6/21 ts-host-install: split the "di" from the "host" command line
In reply to Ian Campbell(i.e. the bit before/after the -- marker). When abstracting over different bootloaders in a future patch this will be convenient since it allows the code to add to either.
--- ts-host-install | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-)
ts-host-install +11 -10
@@ -175,8 +175,8 @@ sub setup_pxeboot_firstboot($) { my $d_i= $ho->{Tftp}{DiBase}.'/'.$r{arch}.'/'.$c{TftpDiVersion}.'-'.$ho->{Suite}; - my @installcmdline= qw(vga=normal); - push @installcmdline, di_installcmdline_core($ho, $ps_url, %xopts); + my @dicmdline= qw(vga=normal); + push @dicmdline, di_installcmdline_core($ho, $ps_url, %xopts); my $src_initrd= "$d_i/initrd.gz"; my @initrds= "$ho->{Tftp}{Path}/$src_initrd";
@@ -265,26 +265,27 @@ END my $initrd= "$ho->{Tftp}{TmpDir}$ho->{Name}--initrd.gz"; system_checked("cat -- @initrds >$ho->{Tftp}{Path}$initrd"); - push @installcmdline, "domain=$c{TestHostDomain}"; - push @installcmdline, + push @dicmdline, "domain=$c{TestHostDomain}"; + push @dicmdline, get_host_property($ho, "install-append $ho->{Suite}", ''), get_host_property($ho, "install-append $ho->{Suite} $r{arch}", ''); my $console = get_host_native_linux_console($ho); - push @installcmdline, "console=$console" unless $console eq "NONE"; + push @dicmdline, "console=$console" unless $console eq "NONE"; - push @installcmdline, qw(--); + my @hocmdline; # See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762007 for # why this is repeated. - push @installcmdline, "console=$console" unless $console eq "NONE"; + push @hocmdline, "console=$console" unless $console eq "NONE"; - push @installcmdline, + push @hocmdline, get_host_property($ho, "linux-boot-append $ho->{Suite}", ''), get_host_property($ho, "linux-boot-append $ho->{Suite} $r{arch}", ''); - my $installcmdline= join ' ', @installcmdline; + my $dicmd= join ' ', @dicmdline; + my $hocmd= join ' ', @hocmdline; setup_pxeboot($ho, <<END); serial 0 $c{Baud}
@@ -293,7 +294,7 @@ label overwrite menu label ^Overwrite menu default kernel $kernel - append initrd=/$initrd $installcmdline + append initrd=/$initrd $dicmd -- $hocmd ipappend $ipappend $dtbs default overwrite
Signature · 1 line
2.1.4
PATCH v4 7/21 Refactor pxelinux configuration
In reply to Ian CampbellThe mechanism used to PXE boot can differ depending on the firmware type. Therefore refactor into Osstest::TestSupport and key off a new host property "firmware".
Currently supported is "bios" (the default) and "uboot", both of which use pxelinux.cfg style files.
The default for the firmware property is "bios", hence no change for any existing system (including those which use uboot, regardless of whether they are now configured with the firmware proprty or not)
As part of this "setup_pxeboot" becomes "setup_pxeboot_di" since it is somewhat d-i specific.
---
v3: reorder setup_${firmware}_pxeboot to setup_pxeboot_${firmware}
join $dicmd in setup_pxeboot instead of caller
--- Osstest/TestSupport.pm | 49 +++++++++++++++++++++++++++++++++++++++++++++---- ts-host-install | 23 ++++++----------------- 2 files changed, 51 insertions(+), 21 deletions(-)
Osstest/TestSupport.pm +45 -4
@@ -104,7 +104,7 @@ BEGIN { await_webspace_fetch_byleaf create_webfile file_link_contents get_timeout - setup_pxeboot setup_pxeboot_local host_pxefile + setup_pxeboot_di setup_pxeboot_local host_pxefile ether_prefix
@@ -2098,16 +2098,34 @@ sub host_pxefile ($;$) { (join ",", sort keys %v)." ?"; } -sub setup_pxeboot ($$) { +sub setup_pxelinux_bootcfg ($$) { my ($ho, $bootfile) = @_; my $f= host_pxefile($ho); file_link_contents("$ho->{Tftp}{Path}$ho->{Tftp}{PxeDir}$f", $bootfile, "$ho->{Name}-pxelinux.cfg"); } -sub setup_pxeboot_local ($) { +# Systems using BIOS are configured to use pxelinux +sub setup_pxeboot_di_bios ($$$$$;%) { + my ($ho,$kern,$initrd,$dicmd,$hocmd,%xopts) = @_; + my $dtbs = "fdtdir $xopts{dtbs}" if $xopts{dtbs}; + setup_pxelinux_bootcfg($ho, <<END); + serial 0 $c{Baud} +timeout 5 +label overwrite + menu label ^Overwrite + menu default + kernel $kern + append $dicmd initrd=$initrd -- $hocmd + ipappend $xopts{ipappend} + $dtbs +default overwrite +END +} + +sub setup_pxeboot_local_bios ($) { my ($ho) = @_; - setup_pxeboot($ho, <<END); + setup_pxelinux_bootcfg($ho, <<END); serial 0 $c{Baud} timeout 5 label local
@@ -2116,6 +2134,29 @@ default local END } +# uboot emulates pxelinux, so reuse BIOS stuff +sub setup_pxeboot_di_uboot ($$$$$;%) { return &setup_pxeboot_di_bios; } +sub setup_pxeboot_local_uboot ($) { return &setup_pxeboot_local_bios; } + +sub setup_pxeboot_local ($) { + my ($ho) = @_; + my $firmware = get_host_property($ho, "firmware", "bios"); + $firmware =~ s/-/_/g; + no strict qw(refs); + return &{"setup_pxeboot_local_${firmware}"}($ho); +} + +sub setup_pxeboot_di ($$$$$;%) { + my ($ho,$kern,$initrd,$dicmd,$hocmd,%xopts) = @_; + my $firmware = get_host_property($ho, "firmware", "bios"); + $firmware =~ s/-/_/g; + no strict qw(refs); + return &{"setup_pxeboot_di_${firmware}"}($ho,$kern,$initrd, + join(' ',@{$dicmd}), + join(' ',@{$hocmd}), + %xopts); +} + #---------- ISO images ---------- sub iso_create_genisoimage ($$$$;@) { my ($ho,$iso,$dir,$isotimeout,@xopts) = @_;
ts-host-install +6 -17
@@ -244,13 +244,14 @@ SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="$ho->{Ether}", A END } - my $dtbs = ""; + my %xopts; + foreach my $kp (keys %{ $ho->{Flags} }) { # Backwards compatibility $kp = "need-kernel-deb-wheezy-backports" if $kp eq "need-kernel-deb-armmp"; $kp =~ s/need-kernel-deb-$ho->{Suite}-// or next; - $dtbs = "fdtdir /$d_i/$kp-dtbs" + $xopts{dtbs} = "/$d_i/$kp-dtbs" if -e "$ho->{Tftp}{Path}/$d_i/$kp-dtbs"; }
@@ -284,21 +285,9 @@ END get_host_property($ho, "linux-boot-append $ho->{Suite}", ''), get_host_property($ho, "linux-boot-append $ho->{Suite} $r{arch}", ''); - my $dicmd= join ' ', @dicmdline; - my $hocmd= join ' ', @hocmdline; - - setup_pxeboot($ho, <<END); -serial 0 $c{Baud} -timeout 5 -label overwrite - menu label ^Overwrite - menu default - kernel $kernel - append initrd=/$initrd $dicmd -- $hocmd - ipappend $ipappend - $dtbs -default overwrite -END + $xopts{ipappend} = $ipappend; + setup_pxeboot_di($ho, $kernel, "/$initrd", \@dicmdline, \@hocmdline, + %xopts); } install();
Signature · 1 line
2.1.4
PATCH v4 8/21 ts-host-install: Support UEFI PXE boot using grub.efi
In reply to Ian CampbellHandling of chainloading from the local hdd in setup_pxeboot_local_uefi will be added in the next patch.
(Wrap DiBase entry in README too for consistency)
---
v4: Turn grub "echo todo" into a die.
v3: Reindent README (fix DiBase too for consistency)
Adjust for reordering of setup_{firmware}_pxeboot to put
{firmware} at end
Rewrap setup_grub_efi_bootcfg
Adjust for setup_pxeboot -> setup_pxeboot_di
--- Osstest/TestSupport.pm | 35 ++++++++++++++++++++++++++++++++++- README | 6 ++++-- 2 files changed, 38 insertions(+), 3 deletions(-)
Osstest/TestSupport.pm +34 -1
@@ -898,7 +898,7 @@ sub selecthost ($) { $ho->{Tftp} = { }; $ho->{Tftp}{$_} = $c{"Tftp${_}_${tftpscope}"} || $c{"Tftp${_}"} foreach qw(Path TmpDir PxeDir PxeGroup PxeTemplates PxeTemplatesReal - DiBase); + DiBase GrubBase); #----- finalise -----
@@ -2138,6 +2138,39 @@ END sub setup_pxeboot_di_uboot ($$$$$;%) { return &setup_pxeboot_di_bios; } sub setup_pxeboot_local_uboot ($) { return &setup_pxeboot_local_bios; } +sub setup_grub_efi_bootcfg ($$) { + my ($ho, $bootfile) = @_; + my $f = "grub.cfg-$ho->{Ether}"; + my $grub= $ho->{Tftp}{Path}.'/'.$ho->{Tftp}{GrubBase}.'/'. + $c{TftpGrubVersion}."/pxegrub-$r{arch}.efi"; + my $pxe=$ho->{Tftp}{Path}.'/'.$ho->{Name}.'/pxe.img'; + + logm("Copy $grub => $pxe"); + copy($grub, $pxe) or die "Copy $grub to $pxe failed: $!"; + + logm("grub_efi bootcfg into $f"); + file_link_contents("$ho->{Tftp}{Path}$ho->{Tftp}{TmpDir}$f", + $bootfile, "$ho->{Name}-pxegrub.cfg"); +} + +# UEFI systems PXE boot using grub.efi +sub setup_pxeboot_di_uefi ($$$$$;%) { + my ($ho,$kern,$initrd,$dicmd,$hocmd,%xopts) = @_; + setup_grub_efi_bootcfg($ho, <<END); +set default=0 +set timeout=5 +menuentry 'overwrite' { + linux $kern $dicmd -- $hocmd + initrd $initrd +} +END +} + +sub setup_pxeboot_local_uefi ($) { + my ($ho) = @_; + die "TODO: setup efi local boot"; +} + sub setup_pxeboot_local ($) { my ($ho) = @_; my $firmware = get_host_property($ho, "firmware", "bios");
README +4 -2
@@ -453,8 +453,10 @@ TftpFoo_<scope> and TftpFoo PxeTemplates See TftpPxeTemplates PxeTemplatesReal - DiBase The path under `Path' to the root of the debian installer - images. + DiBase The path under `Path' to the root of the debian + installer images. + GrubBase The path under `Path' to the root of the grub + EFI PXE images. For hosts in scope "default", TftpFoo_default (if set) takes precedence over TftpFoo. TftpFoo is used when the setting Foo is
Signature · 1 line
2.1.4
PATCH v4 9/21 Enable chain loading to local disk for UEFI PXE systems.
In reply to Ian CampbellFirst arrange for bootloader to be installed to removable media path, by using a new in Jessie preseed option. Then use that to chainload a bootloader from the disk.
The removable media path is well known (part of the UEFI spec) which saves us having to worry about which OS is on the host (so long as the OS can be configured to populate the removable media path)
--- Osstest/Debian.pm | 2 ++ Osstest/TestSupport.pm | 20 +++++++++++++++++++- 2 files changed, 21 insertions(+), 1 deletion(-)
Osstest/Debian.pm +2 -0
@@ -757,6 +757,8 @@ d-i apt-setup/contrib boolean false d-i pkgsel/include string openssh-server, ntp, ntpdate, ethtool, chiark-utils-bin, $extra_packages +d-i grub-installer/force-efi-extra-removable boolean true + $xopts{ExtraPreseed} END
Osstest/TestSupport.pm +19 -1
@@ -2168,7 +2168,25 @@ END sub setup_pxeboot_local_uefi ($) { my ($ho) = @_; - die "TODO: setup efi local boot"; + my %efi_archs = qw(amd64 X64 + arm32 ARM + arm64 AARCH64 + i386 IA32); + die "EFI arch" unless $efi_archs{ $r{arch} }; + my $efi = $efi_archs{ $r{arch} }; + setup_grub_efi_bootcfg($ho, <<END); +set default=0 +set timeout=5 +menuentry 'local' { + insmod chain + insmod part_gpt + insmod part_msdos + set root=(hd0,gpt1) + echo "Chainloading (\${root})/EFI/BOOT/BOOTAA64.EFI" + chainloader (\${root})/EFI/BOOT/BOOTAA64.EFI + boot +} +END } sub setup_pxeboot_local ($) {
Signature · 1 line
2.1.4
PATCH v4 10/21 Add arm64 build and test jobs
In reply to Ian CampbellRunvars:
build-arm64 arch arm64 build-arm64 build_lvextend_max 50 build-arm64 enable_ovmf true build-arm64 enable_xend false build-arm64 enable_xsm false build-arm64 host_hostflags share-build-jessie-arm64,arch-arm64,suite-jessie,purpose-build build-arm64 revision_ovmf build-arm64 revision_qemu build-arm64 revision_qemuu b2da824bc5ad35fb9f1e74a203d7be96a7b0345e build-arm64 revision_seabios build-arm64 revision_xen e13013dbf1d5997915548a3b5f1c39594d8c1d7b build-arm64 tree_ovmf build-arm64 tree_qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git build-arm64 tree_qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git build-arm64 tree_seabios build-arm64 tree_xen git://xenbits.xen.org/xen.git build-arm64-libvirt arch arm64 build-arm64-libvirt build_lvextend_max 50 build-arm64-libvirt buildjob build-arm64 build-arm64-libvirt host_hostflags share-build-jessie-arm64,arch-arm64,suite-jessie,purpose-build build-arm64-libvirt revision_libvirt fd74e231751334b64af0934b680c5cc62f652453 build-arm64-libvirt tree_libvirt git://xenbits.xen.org/libvirt.git build-arm64-libvirt tree_xen git://xenbits.xen.org/xen.git build-arm64-pvops arch arm64 build-arm64-pvops build_lvextend_max 50 build-arm64-pvops host_hostflags share-build-jessie-arm64,arch-arm64,suite-jessie,purpose-build build-arm64-pvops kconfig_override_y CONFIG_EXT4_FS build-arm64-pvops kconfighow xen-enable-xen-config build-arm64-pvops revision_linux ec18c9fc039971041d854e0d58551f1f1a32ff8f build-arm64-pvops revision_linuxfirmware c530a75c1e6a472b0eb9558310b518f0dfcd8860 build-arm64-pvops tree_linux git://xenbits.xen.org/linux-pvops.git build-arm64-pvops tree_linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git build-arm64-pvops treevcs_linux git build-arm64-xsm arch arm64 build-arm64-xsm build_lvextend_max 50 build-arm64-xsm enable_ovmf true build-arm64-xsm enable_xend false build-arm64-xsm enable_xsm true build-arm64-xsm host_hostflags share-build-jessie-arm64,arch-arm64,suite-jessie,purpose-build build-arm64-xsm revision_ovmf build-arm64-xsm revision_qemu build-arm64-xsm revision_qemuu b2da824bc5ad35fb9f1e74a203d7be96a7b0345e build-arm64-xsm revision_seabios build-arm64-xsm revision_xen e13013dbf1d5997915548a3b5f1c39594d8c1d7b build-arm64-xsm tree_ovmf build-arm64-xsm tree_qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git build-arm64-xsm tree_qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git build-arm64-xsm tree_seabios build-arm64-xsm tree_xen git://xenbits.xen.org/xen.git test-arm64-arm64-libvirt all_hostflags arch-arm64,arch-xen-arm64,suite-jessie,purpose-test test-arm64-arm64-libvirt arch arm64 test-arm64-arm64-libvirt buildjob build-arm64 test-arm64-arm64-libvirt debian_arch arm64 test-arm64-arm64-libvirt debian_kernkind pvops test-arm64-arm64-libvirt enable_xsm false test-arm64-arm64-libvirt kernbuildjob build-arm64-pvops test-arm64-arm64-libvirt kernkind pvops test-arm64-arm64-libvirt libvirtbuildjob build-arm64-libvirt test-arm64-arm64-libvirt toolstack libvirt test-arm64-arm64-libvirt xenbuildjob build-arm64 test-arm64-arm64-libvirt-xsm all_hostflags arch-arm64,arch-xen-arm64,suite-jessie,purpose-test test-arm64-arm64-libvirt-xsm arch arm64 test-arm64-arm64-libvirt-xsm buildjob build-arm64-xsm test-arm64-arm64-libvirt-xsm debian_arch arm64 test-arm64-arm64-libvirt-xsm debian_kernkind pvops test-arm64-arm64-libvirt-xsm enable_xsm true test-arm64-arm64-libvirt-xsm kernbuildjob build-arm64-pvops test-arm64-arm64-libvirt-xsm kernkind pvops test-arm64-arm64-libvirt-xsm libvirtbuildjob build-arm64-libvirt test-arm64-arm64-libvirt-xsm toolstack libvirt test-arm64-arm64-libvirt-xsm xenbuildjob build-arm64-xsm test-arm64-arm64-xl all_hostflags arch-arm64,arch-xen-arm64,suite-jessie,purpose-test test-arm64-arm64-xl arch arm64 test-arm64-arm64-xl buildjob build-arm64 test-arm64-arm64-xl debian_arch arm64 test-arm64-arm64-xl debian_kernkind pvops test-arm64-arm64-xl enable_xsm false test-arm64-arm64-xl kernbuildjob build-arm64-pvops test-arm64-arm64-xl kernkind pvops test-arm64-arm64-xl toolstack xl test-arm64-arm64-xl xenbuildjob build-arm64 test-arm64-arm64-xl-credit2 all_hostflags arch-arm64,arch-xen-arm64,suite-jessie,purpose-test test-arm64-arm64-xl-credit2 arch arm64 test-arm64-arm64-xl-credit2 buildjob build-arm64 test-arm64-arm64-xl-credit2 debian_arch arm64 test-arm64-arm64-xl-credit2 debian_kernkind pvops test-arm64-arm64-xl-credit2 guests_vcpus 4 test-arm64-arm64-xl-credit2 kernbuildjob build-arm64-pvops test-arm64-arm64-xl-credit2 kernkind pvops test-arm64-arm64-xl-credit2 toolstack xl test-arm64-arm64-xl-credit2 xen_boot_append sched=credit2 test-arm64-arm64-xl-credit2 xenbuildjob build-arm64 test-arm64-arm64-xl-multivcpu all_hostflags arch-arm64,arch-xen-arm64,suite-jessie,purpose-test test-arm64-arm64-xl-multivcpu arch arm64 test-arm64-arm64-xl-multivcpu buildjob build-arm64 test-arm64-arm64-xl-multivcpu debian_arch arm64 test-arm64-arm64-xl-multivcpu debian_kernkind pvops test-arm64-arm64-xl-multivcpu guests_vcpus 4 test-arm64-arm64-xl-multivcpu kernbuildjob build-arm64-pvops test-arm64-arm64-xl-multivcpu kernkind pvops test-arm64-arm64-xl-multivcpu toolstack xl test-arm64-arm64-xl-multivcpu xenbuildjob build-arm64 test-arm64-arm64-xl-sedf all_hostflags arch-arm64,arch-xen-arm64,suite-jessie,purpose-test test-arm64-arm64-xl-sedf arch arm64 test-arm64-arm64-xl-sedf buildjob build-arm64 test-arm64-arm64-xl-sedf debian_arch arm64 test-arm64-arm64-xl-sedf debian_kernkind pvops test-arm64-arm64-xl-sedf guests_vcpus 4 test-arm64-arm64-xl-sedf kernbuildjob build-arm64-pvops test-arm64-arm64-xl-sedf kernkind pvops test-arm64-arm64-xl-sedf linux_boot_append loglevel=9 debug test-arm64-arm64-xl-sedf toolstack xl test-arm64-arm64-xl-sedf xen_boot_append sched=sedf loglvl=all test-arm64-arm64-xl-sedf xenbuildjob build-arm64 test-arm64-arm64-xl-sedf-pin all_hostflags arch-arm64,arch-xen-arm64,suite-jessie,purpose-test test-arm64-arm64-xl-sedf-pin arch arm64 test-arm64-arm64-xl-sedf-pin buildjob build-arm64 test-arm64-arm64-xl-sedf-pin debian_arch arm64 test-arm64-arm64-xl-sedf-pin debian_kernkind pvops test-arm64-arm64-xl-sedf-pin guests_vcpus 4 test-arm64-arm64-xl-sedf-pin kernbuildjob build-arm64-pvops test-arm64-arm64-xl-sedf-pin kernkind pvops test-arm64-arm64-xl-sedf-pin linux_boot_append loglevel=9 debug test-arm64-arm64-xl-sedf-pin toolstack xl test-arm64-arm64-xl-sedf-pin xen_boot_append sched=sedf loglvl=all dom0_vcpus_pin test-arm64-arm64-xl-sedf-pin xenbuildjob build-arm64 test-arm64-arm64-xl-xsm all_hostflags arch-arm64,arch-xen-arm64,suite-jessie,purpose-test test-arm64-arm64-xl-xsm arch arm64 test-arm64-arm64-xl-xsm buildjob build-arm64-xsm test-arm64-arm64-xl-xsm debian_arch arm64 test-arm64-arm64-xl-xsm debian_kernkind pvops test-arm64-arm64-xl-xsm enable_xsm true test-arm64-arm64-xl-xsm kernbuildjob build-arm64-pvops test-arm64-arm64-xl-xsm kernkind pvops test-arm64-arm64-xl-xsm toolstack xl test-arm64-arm64-xl-xsm xenbuildjob build-arm64-xsm
---
--- make-flight | 4 ++-- mfi-common | 23 ++++++++++++++++++----- ts-kernel-build | 1 + 3 files changed, 21 insertions(+), 7 deletions(-)
make-flight +2 -2
@@ -107,7 +107,7 @@ job_create_test_filter_callback () { test_matrix_branch_filter_callback () { case "$xenarch" in - armhf) + armhf|arm64) case "$branch" in linux-3.0) return 1;; linux-3.4) return 1;;
@@ -366,7 +366,7 @@ test_matrix_do_one () { do_credit2_tests # No further arm tests at the moment - if [ $dom0arch = armhf ]; then + if [ $dom0arch = armhf ] || [ $dom0arch = arm64 ]; then return fi
mfi-common +18 -5
@@ -67,12 +67,12 @@ create_build_jobs () { BUILD_RUNVARS+=" build_lvextend_max=$BUILD_LVEXTEND_MAX " fi - for arch in ${BUILD_ARCHES- i386 amd64 armhf }; do + for arch in ${BUILD_ARCHES- i386 amd64 armhf arm64 }; do if [ "x$arch" = xdisable ]; then continue; fi case "$arch" in - armhf) + armhf|arm64) case "$branch" in linux-3.0) continue;; linux-3.4) continue;;
@@ -247,7 +247,7 @@ create_build_jobs () { fi case "$arch" in - armhf) continue;; # don't do any other kernel builds + armhf|arm64) continue;; # don't do any other kernel builds esac if [ "x$REVISION_LINUX_OLD" != xdisable ]; then
@@ -319,13 +319,25 @@ test_matrix_iterate () { *) onetoolstack=xl ;; esac - for xenarch in ${TEST_ARCHES- i386 amd64 armhf } ; do + for xenarch in ${TEST_ARCHES- i386 amd64 armhf arm64 } ; do if [ "x$xenarch" = xdisable ]; then continue; fi test_matrix_branch_filter_callback || continue case "$xenarch" in + arm64) + # Arm64 from 4.5 onwards only + case "$xenbranch" in + xen-3.*-testing) continue;; + xen-4.0-testing) continue;; + xen-4.1-testing) continue;; + xen-4.2-testing) continue;; + xen-4.3-testing) continue;; + xen-4.4-testing) continue;; + *) ;; + esac + ;; armhf) # Arm from 4.3 onwards only case "$xenbranch" in
@@ -370,13 +382,14 @@ test_matrix_iterate () { *) echo >&2 "kernkind ? $kern"; exit 1 ;; esac - for dom0arch in i386 amd64 armhf; do + for dom0arch in i386 amd64 armhf arm64; do case ${xenarch}_${dom0arch} in amd64_amd64) ;; amd64_i386) ;; i386_i386) ;; armhf_armhf) ;; + arm64_arm64) ;; *) continue ;; esac
ts-kernel-build +1 -0
@@ -39,6 +39,7 @@ builddirsprops(); my $archparms = { 'armhf' => { DefConfig => 'multi_v7_defconfig', KernelImage => 'arch/arm/boot/zImage' }, + 'arm64' => { DefConfig => 'defconfig', KernelImage => 'arch/arm64/boot/Image' }, 'i386' => { DefConfig => 'defconfig', KernelImage => 'arch/x86/boot/bzImage' }, 'amd64' => { DefConfig => 'defconfig', KernelImage => 'arch/x86/boot/bzImage' } };
Signature · 1 line
2.1.4
PATCH v4 11/21 ts-kernel-build: Additional kernel options for Mustang
In reply to Ian Campbell---
Note: ARM testing currently uses a 3.16 based linux-arm-xen kernel (compared to 3.14 currently used as the default). In order to support Mustang something newer is needed, I've been testing 4.1 (next LTS kernel), 3.18 (the intervening LTS kernel) might be sufficient but I haven't tried it. We should plan to either update linux-arm-xen or the default kernel version at some point before we get Mustang h/w.
v3: Set CONFIG_NET_XGENE (was commented out before)
Remove setting of CONFIG_SPARSEMEM_VMEMMAP
--- ts-kernel-build | 7 +++++++ 1 file changed, 7 insertions(+)
ts-kernel-build +7 -0
@@ -542,6 +542,13 @@ setopt CONFIG_BLK_CPQ_CISS_DA m setopt CONFIG_FHANDLE y +# APM XGENE +setopt CONFIG_PHY_XGENE y +setopt CONFIG_NET_XGENE y +setopt CONFIG_AHCI_XGENE y +setopt CONFIG_POWER_RESET_XGENE y +setopt CONFIG_RTC_DRV_XGENE y + case ${XEN_TARGET_ARCH} in x86_32) setopt CONFIG_64BIT n ;; x86_64)
Signature · 1 line
2.1.4
PATCH v4 12/21 ts-kernel-build: Enable CONFIG_EFI_VARS
In reply to Ian CampbellWhich makes efibootmgr work when running our kernel.
---
v3: New patch
--- ts-kernel-build | 3 +++ 1 file changed, 3 insertions(+)
ts-kernel-build +3 -0
@@ -542,6 +542,9 @@ setopt CONFIG_BLK_CPQ_CISS_DA m setopt CONFIG_FHANDLE y +# Needed for efibootmgr +setopt CONFIG_EFI_VARS y + # APM XGENE setopt CONFIG_PHY_XGENE y setopt CONFIG_NET_XGENE y
Signature · 1 line
2.1.4
PATCH v4 13/21 ts-host-install: Set dtbs in the non-special kernel case too.
In reply to Ian CampbellWhen DTB support was added for armhf it required a backports kernel for use with Wheezy and therefore DTBs were only collected for that special case. However as we move forward to newer kernels it should be possible to run using the proper kernel (e.g. Jessie should work for armhf). Therefore we will need the DTBs for those kernels too.
---
v3: Improved commit message
--- ts-host-install | 3 +++ 1 file changed, 3 insertions(+)
ts-host-install +3 -0
@@ -255,6 +255,9 @@ END if -e "$ho->{Tftp}{Path}/$d_i/$kp-dtbs"; } + $xopts{dtbs} = "/$d_i/dtbs" + if !$xopts{dtbs} && -e "$ho->{Tftp}{Path}/$d_i/dtbs"; + file_simple_write_contents("$initrd_overlay.cpio", sub { contents_make_cpio($_[0], 'newc', "$initrd_overlay.d"); });
Signature · 1 line
2.1.4
PATCH v4 14/21 Debian: Do not add Debian to UEFI boot order on install
In reply to Ian CampbellBy default Debian inserts itself before any existing entries, including the PXE one, meaning we otherwise cannot remotely regroove the box.
Add a hook to /usr/lib/base-installer.d/ which installs a diversion of /usr/sbin/grub-install and installs a wrapper which adds the --no-nvram argument which prevents grub-install from adding the boot entries.
---
v4: Die on !jessie
v3: New patch replacing "Debian: Fixup UEFI boot order during install"
--- Osstest/Debian.pm | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+)
Osstest/Debian.pm +25 -0
@@ -1018,6 +1018,31 @@ END preseed_microcode($ho,$sfx); + if (get_host_property($ho, "firmware") eq "uefi") { + die unless $ho->{Suite} =~ m/jessie/; + # Prevent grub-install from making a new Debian boot entry, so + # we always reboot from PXE. Debian bug #789798 proposes a + # properly preseedable solution to this. + preseed_hook_installscript($ho, $sfx, + '/usr/lib/base-installer.d/', + 'osstest-disable-grub-nvram', <<'END'); +#!/bin/sh +set -ex + +logger -t osstest-disable-grub-nvram "Adding our grub-install wrapper" + +t=/usr/sbin/grub-install + +in-target dpkg-divert --divert $t.osstest --rename --add $t + +cat >/target/$t <<EOF +#!/bin/sh +exec $t.osstest --no-nvram \$@ +EOF +chmod +x /target/$t +END + } + $preseed_file .= preseed_hook_cmds(); if ($ho->{Flags}{'no-di-kernel'}) {
Signature · 1 line
2.1.4
PATCH v4 15/21 standalone: Prefer ./local-config to $HOME/.xen-osstest/config
In reply to Ian CampbellOSSTEST_CONFIG still trumps both.
---
v3: local-config not standalone.config
--- standalone | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
standalone +7 -1
@@ -68,7 +68,13 @@ TEMP=$(getopt -o c:f:h:rRs --long config:,flight:,host:,reuse,noreuse,reinstall, eval set -- "$TEMP" -config=${OSSTEST_CONFIG-$HOME/.xen-osstest/config} +if [ -n "${OSSTEST_CONFIG}" ]; then + config=${OSSTEST_CONFIG} +elif [ -f local-config ]; then + config=local-config +else + config=$HOME/.xen-osstest/config +fi flight="standalone" host= reuse=1 # Don't blow away machines by default
Signature · 1 line
2.1.4
PATCH v4 16/21 Debian: grub2: Log full line range of menuentry and submenu entries
In reply to Ian CampbellIs useful when debugging.
--- Osstest/Debian.pm | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-)
Osstest/Debian.pm +4 -5
@@ -412,8 +412,7 @@ sub setupboot_grub2 ($$$$) { if (m/^\s*\}\s*$/) { die unless $entry || $submenu; if (!defined $entry && defined $submenu) { - logm("Met end of a submenu starting from ". - "$submenu->{StartLine}. ". + logm("Met end of a submenu $submenu->{StartLine}..$.. ". "Our want kern is $want_kernver"); $submenu=undef; pop @offsets;
@@ -426,14 +425,14 @@ sub setupboot_grub2 ($$$$) { ? qw(Title Hv KernDom0 KernVer) : qw(Title Hv KernOnly KernVer)); if (@missing) { - logm("(skipping entry at $entry->{StartLine};". + logm("(skipping entry at $entry->{StartLine}..$.;". " no @missing)"); } elsif (defined $want_kernver && $entry->{KernVer} ne $want_kernver) { - logm("(skipping entry at $entry->{StartLine};". + logm("(skipping entry at $entry->{StartLine}..$.;". " kernel $entry->{KernVer}, not $want_kernver)"); } elsif ($want_xsm && !defined $entry->{Xenpolicy}) { - logm("(skipping entry at $entry->{StartLine};". + logm("(skipping entry at $entry->{StartLine}..$.;". " XSM policy file not present)"); } else { # yes!
Signature · 1 line
2.1.4
PATCH v4 17/21 Debian: grub2: Use GRUB_CMDLINE_LINUX_XEN_REPLACE(_DEFAULT)
In reply to Ian CampbellThis overrides GRUB_CMDLINE_LINUX(_DEFAULT) which we were previously editing but only for the Xen entries, meaning that we don't switch to console=hvc0 for the native cases (i.e. don't break them).
We do however want to edit GRUB_CMDLINE_LINUX(_DEFAULT) to remove "quiet" if present, since it is useful to people, especially those using standalone mode as a provisioning tool, wanting to e.g. compare a boot under Xen with the native case.
This has been supported since Wheezy but in any case we supply our own 20_linux_xen grub generator based on Wheezy which supports this.
--- Osstest/Debian.pm | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-)
Osstest/Debian.pm +12 -3
@@ -507,7 +507,7 @@ sub setupboot_grub2 ($$$$) { $v =~ s/^\s*([\'\"])(.*)\1\s*$/$2/; $k{$k}= $v; } - next if m/^GRUB_CMDLINE_(?:XEN|LINUX).*\=|^GRUB_DEFAULT.*\=/; + next if m/^GRUB_CMDLINE_(?:XEN|LINUX(?:_XEN_REPLACE)?(?:_DEFAULT)?).*\=|^GRUB_DEFAULT.*\=/; print ::EO; } print ::EO <<END or die $!;
@@ -521,11 +521,20 @@ GRUB_CMDLINE_XEN="$xenhopt" END foreach my $k (qw(GRUB_CMDLINE_LINUX GRUB_CMDLINE_LINUX_DEFAULT)) { my $v= $k{$k}; + + # Tailor native case $v =~ s/\bquiet\b//; + print ::EO "$k=\"$v\"\n" or die $!; + + # Xen overrides $v =~ s/\b(?:console|xencons)=[0-9A-Za-z,]+//; $v .= " $xenkopt" if $k eq 'GRUB_CMDLINE_LINUX'; - print ::EO "$k=\"$v\"\n" or die $!; - } + # Ensure variable isn't zero length, or 20_linux_xen will ignore it. + $v .= " "; + my $rk = $k; + $rk =~ s/LINUX/LINUX_XEN_REPLACE/; + print ::EO "$rk=\"$v\"\n" or die $!; + } }); };
Signature · 1 line
2.1.4
PATCH v4 18/21 Collect xen.efi into xendist and install in appropriate place
In reply to Ian CampbellPreviously these binaries would have been included in the regular ("tools") dist file, whereas they really belong in the xen one.
Install into /boot/efi/EFI/osstest ready for use when chainloading.
Note that /boot/efi is (or should be) a VFAT filesystem. So a bit of care is needed WRT symlinks etc. This is also what prevents us from just including /boot/efi/EFI/osstest/xen.efi in the dist tarball since untarring over a VFAT needs a little care WRT the case of directories etc.
--- ts-xen-build | 7 +++++++ ts-xen-install | 7 +++++++ 2 files changed, 14 insertions(+)
ts-xen-build +7 -0
@@ -172,6 +172,13 @@ sub divide () { mv \$mvfiles xeninstall/boot/. fi fi + if test -d install/usr/lib64/efi/; then + if test -f install/usr/lib64/efi/xen.efi; then + mkdir -p xeninstall/usr/lib64/efi + mvfiles=`find install/usr/lib64/efi -name 'xen[a-z]*' -prune -o -name 'xen*' -print` + mv \$mvfiles xeninstall/usr/lib64/efi/. + fi + fi END }
ts-xen-install +7 -0
@@ -77,6 +77,13 @@ sub extract () { target_extract_jobdistpath($ho, $part, "path_${part}dist", $r{"${part}buildjob"}, \%distpath); } + if (target_file_exists($ho, "/usr/lib64/efi/xen.efi")) { + target_cmd_root($ho,<<END); + mkdir -p /boot/efi/EFI/osstest + # /boot/efi is VFAT, so dereference the symlink + cp -vL /usr/lib64/efi/xen.efi /boot/efi/EFI/osstest +END + } target_cmd_root($ho, '/sbin/ldconfig'); }
Signature · 1 line
2.1.4
PATCH v4 19/21 Debian: Ignore xen-syms entries in grub.cfg.
In reply to Ian CampbellThese can't (in general?) actually be booted.
--- Osstest/Debian.pm | 3 +++ 1 file changed, 3 insertions(+)
Osstest/Debian.pm +3 -0
@@ -427,6 +427,9 @@ sub setupboot_grub2 ($$$$) { if (@missing) { logm("(skipping entry at $entry->{StartLine}..$.;". " no @missing)"); + } elsif ($entry->{Hv} =~ m/xen-syms/) { + logm("(skipping entry at $entry->{StartLine}..$.;". + " is xen-syms)"); } elsif (defined $want_kernver && $entry->{KernVer} ne $want_kernver) { logm("(skipping entry at $entry->{StartLine}..$.;".
Signature · 1 line
2.1.4
PATCH v4 20/21 Debian: Collect kernel command line from grub.cfg
In reply to Ian CampbellI'm going to want it in a subsequent patch
--- Osstest/Debian.pm | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
Osstest/Debian.pm +4 -2
@@ -460,15 +460,17 @@ sub setupboot_grub2 ($$$$) { die unless $entry; $entry->{Hv}= $1; } - if (m/^\s*multiboot\s*(?:\/boot)?\/(vmlinu[xz]-(\S+))/) { + if (m/^\s*multiboot\s*(?:\/boot)?\/(vmlinu[xz]-(\S+))\s+(.*)/) { die unless $entry; $entry->{KernOnly}= $1; $entry->{KernVer}= $2; + $entry->{KernOpts}= $3; } - if (m/^\s*module\s*(?:\/boot)?\/(vmlinu[xz]-(\S+))/) { + if (m/^\s*module\s*(?:\/boot)?\/(vmlinu[xz]-(\S+))\s+(.*)/) { die unless $entry; $entry->{KernDom0}= $1; $entry->{KernVer}= $2; + $entry->{KernOpts}= $3; } if (m/^\s*module\s*(?:\/boot)?\/(initrd\S+)/) { $entry->{Initrd}= $1;
Signature · 1 line
2.1.4
PATCH v4 21/21 Debian: Arrange to be able to chainload a xen.efi from grub2
In reply to Ian CampbellXen cannot (currently) be booted directly via the usual multiboot path on EFI systems of any arch. Instead it is necessary to either launch xen.efi direct from the UEFI shell or to chainload it from grub. In both cases the Xen command line as well as what would normally be the multiboot modules (kernel+command line, XSM policy, initrd) must be configured in a Xen configuration file.
Here we add a new overlay/etc/grub.d/15_osstest_uefi grub script which arranges that if a xen.efi is found in the EFI System Partition (as arrange by a previous patch) a suitable entry is created in grub.cfg as well.
When parsing the grub.cfg look for such an entry into addition to the regular/multiboot one and when necessary write the configuration file based on the regular entry and return the chainload one such that it gets booted.
This is currently enabled only for Jessie ARM64 systems.
---
v4: Use a separate grub script snippet, there's nothing we need in
20_linux_xen
v3: Rewrap and reindent to avoid long lines
Split out boot script
--- Osstest/Debian.pm | 77 +++++++++++++++++++++++++++++++++++++- overlay/etc/grub.d/15_osstest_uefi | 49 ++++++++++++++++++++++++ 2 files changed, 124 insertions(+), 2 deletions(-) create mode 100755 overlay/etc/grub.d/15_osstest_uefi
Osstest/Debian.pm +75 -2
@@ -400,12 +400,18 @@ sub setupboot_grub2 ($$$$) { my $rmenu= '/boot/grub/grub.cfg'; my $kernkey= (defined $xenhopt ? 'KernDom0' : 'KernOnly'); - + + # Grub2 on Jessie/arm* doesn't do multiboot, so we must chainload. + my $need_uefi_chainload = + get_host_property($ho, "firmware") eq "uefi" && + $ho->{Suite} =~ m/jessie/ && $r{arch} =~ m/^arm/; + my $parsemenu= sub { my $f= bl_getmenu_open($ho, $rmenu, "$stash/$ho->{Name}--grub.cfg.1"); my @offsets = (0); my $entry; + my $chainentry; my $submenu; while (<$f>) { next if m/^\s*\#/ || !m/\S/;
@@ -424,7 +430,13 @@ sub setupboot_grub2 ($$$$) { (defined $xenhopt ? qw(Title Hv KernDom0 KernVer) : qw(Title Hv KernOnly KernVer)); - if (@missing) { + if ($need_uefi_chainload && $entry->{Chainload}) { + # Needs to be before check of @missing, since a + # chained entry doesn't have anything useful in it + logm("Found chainload entry at $entry->{StartLine}..$."); + die "already got one" if $chainentry; + $chainentry = $entry; + } elsif (@missing) { logm("(skipping entry at $entry->{StartLine}..$.;". " no @missing)"); } elsif ($entry->{Hv} =~ m/xen-syms/) {
@@ -456,9 +468,15 @@ sub setupboot_grub2 ($$$$) { $submenu={ StartLine =>$., MenuEntryPath => join ">", @offsets }; push @offsets,(0); } + if (m/^\s*chainloader\s*\/EFI\/osstest\/xen.efi/) { + die unless $entry; + $entry->{Hv}= $1; + $entry->{Chainload} = 1; + } if (m/^\s*multiboot\s*(?:\/boot)?\/(xen\S+)/) { die unless $entry; $entry->{Hv}= $1; + $entry->{Chainload} = 0; } if (m/^\s*multiboot\s*(?:\/boot)?\/(vmlinu[xz]-(\S+))\s+(.*)/) { die unless $entry;
@@ -490,13 +508,68 @@ sub setupboot_grub2 ($$$$) { die unless $entry->{Hv}; } + if ($need_uefi_chainload) { + die 'chainload entry not found' unless $chainentry; + + # Propagate relevant fields of the main entry over to the + # chain entry for use of subsequent code. + foreach (qw(KernVer KernDom0 KernOnly KernOpts + Initrd Xenpolicy)) { + next unless $entry->{$_}; + die if $chainentry->{$_}; + $chainentry->{$_} = $entry->{$_}; + } + + $entry = $chainentry; + } + return $entry; }; $bl->{UpdateConfig}= sub { my ( $ho ) = @_; + + target_editfile_root($ho, '/etc/default/grub', sub { + while (<::EI>) { + next if m/^export GRUB_ENABLE_XEN_UEFI_CHAINLOAD\=/; + print ::EO; + } + print ::EO "export GRUB_ENABLE_XEN_UEFI_CHAINLOAD=\"osstest\"\n" + if $need_uefi_chainload; + }); + target_cmd_root($ho, "update-grub"); + + if ($need_uefi_chainload) { + my $entry= $parsemenu->(); + my $xencfg = <<END; +[global] +default=osstest + +[osstest] +options=$xenhopt +kernel=vmlinuz $entry->{KernOpts} +END + $xencfg .= "ramdisk=initrd.gz\n" if $entry->{Initrd}; + $xencfg .= "xsm=xenpolicy\n" if $entry->{Xenpolicy}; + + target_putfilecontents_root_stash($ho,30,$xencfg, + "/boot/efi/EFI/osstest/xen.cfg"); + + # /boot/efi should be a mounted EFI system partition, and + # /boot/efi/EFI/osstest/xen.efi should already exist. Hence no mkdir + # here. + target_cmd_root($ho, + <<END.($entry->{Initrd}?<<END:"").($entry->{Xenpolicy}?<<END:"")); +set -ex +cp -vL /boot/$entry->{KernDom0} /boot/efi/EFI/osstest/vmlinuz #/ +END +cp -vL /boot/$entry->{Initrd} /boot/efi/EFI/osstest/initrd.gz #/ +END +cp -vL /boot/$entry->{Xenpolicy} /boot/efi/EFI/osstest/xenpolicy #/ +END + } }; $bl->{GetBootKern}= sub { return $parsemenu->()->{$kernkey}; };
overlay/etc/grub.d/15_osstest_uefi new file +49 -0
49 lines not on this page · raw message
Signature · 1 line
2.1.4
Re: [PATCH OSSTEST v4 21/21] Debian: Arrange to be able to chainload a xen.efi from grub2
Ian Campbell writes ("[PATCH OSSTEST v4 21/21] Debian: Arrange to be able to chainload a xen.efi from grub2"):
Quoted 12 lines
Xen cannot (currently) be booted directly via the usual multiboot path on EFI systems of any arch. Instead it is necessary to either launch xen.efi direct from the UEFI shell or to chainload it from grub. In both cases the Xen command line as well as what would normally be the multiboot modules (kernel+command line, XSM policy, initrd) must be configured in a Xen configuration file.
Here we add a new overlay/etc/grub.d/15_osstest_uefi grub script which arranges that if a xen.efi is found in the EFI System Partition (as arrange by a previous patch) a suitable entry is created in grub.cfg as well.
Quoted 8 lines
When parsing the grub.cfg look for such an entry into addition to the regular/multiboot one and when necessary write the configuration file based on the regular entry and return the chainload one such that it gets booted.
This is currently enabled only for Jessie ARM64 systems.
Signed-off-by Ian Campbell <[email protected]>
Ian Campbell writes ("[Xen-devel] [PATCH OSSTEST v4 00/21] Initial support for ARM64"):
Quoted 5 lines
I've addressed the issues raised last time and dropped the VMEMMMAP hack since it is now understood. I retained acks on the two mg-* changes despite folding everything into mgi-common as well as the "die on ! jessie" change to the UEFI boot order bodge, since all that seemed minor enough, I hope that's ok:
Right.
Quoted 1 line
M Debian: Arrange to be able to chainload a xen.efi from grub2
Now acked too.
Quoted 7 lines
That's all bar the final patch acked I think. However we haven't yet got any hardware and this is dependent on a switch to Jessie for tests. I support we don't want to just take this directly and let the tests be failing ts-host-allocate since that will just add noise to the reports. I could put this to one side and rebase once h/w shows up, or I could tweak mfi-common to omit arm64 from (BUILD|TEST)_ARCHES for now and we could apply it.
I think it would be better to have as much of this in-tree as possible.
Can we bubble this patch:
Quoted 1 line
A Add arm64 build and test jobs
to the end ?
If so we could apply all the rest.
Ian.
Quoted 24 lines · Ian Jackson
Ian Campbell writes ("[Xen-devel] [PATCH OSSTEST v4 00/21] Initial support for ARM64"):
Quoted 5 lines
I've addressed the issues raised last time and dropped the VMEMMMAP hack since it is now understood. I retained acks on the two mg-* changes despite folding everything into mgi-common as well as the "die on ! jessie" change to the UEFI boot order bodge, since all that seemed minor enough, I hope that's ok:
Right.
Quoted 1 line
M Debian: Arrange to be able to chainload a xen.efi from grub2
Now acked too.
Quoted 7 lines
That's all bar the final patch acked I think. However we haven't yet got any hardware and this is dependent on a switch to Jessie for tests. I support we don't want to just take this directly and let the tests be failing ts-host-allocate since that will just add noise to the reports. I could put this to one side and rebase once h/w shows up, or I could tweak mfi-common to omit arm64 from (BUILD|TEST)_ARCHES for now and we could apply it.
I think it would be better to have as much of this in-tree as possible.
Quoted 7 lines
Can we bubble this patch:
Quoted 1 line
A Add arm64 build and test jobs
to the end ?
If so we could apply all the rest.
I did so with rebase -i with no complaints. So either you could apply skipping that one, or I could push the result in whichever convenient window you like.
Quoted 2 lines
Ian.
Ian Campbell writes ("Re: [Xen-devel] [PATCH OSSTEST v4 00/21] Initial support for ARM64"):
Quoted 10 lines · Ian Jackson
Quoted 5 lines
Can we bubble this patch:
Quoted 1 line
A Add arm64 build and test jobs
to the end ?
If so we could apply all the rest.
I did so with rebase -i with no complaints. So either you could apply skipping that one, or I could push the result in whichever convenient window you like.
I think we can probably push the rest some time at the weekend.
If you put the branch somewhere I can fetch it I will take a quick look some time late on Saturday or on Sunday.
Ian.
Quoted 8 lines · Ian Jackson
Ian Campbell writes ("Re: [Xen-devel] [PATCH OSSTEST v4 00/21] Initial support for ARM64"):
Quoted 7 lines · Ian Jackson
Quoted 5 lines
Can we bubble this patch:
Quoted 1 line
A Add arm64 build and test jobs
to the end ?
If so we could apply all the rest.
Quoted 7 lines
Quoted 3 lines
I did so with rebase -i with no complaints. So either you could apply skipping that one, or I could push the result in whichever convenient window you like.
I think we can probably push the rest some time at the weekend.
If you put the branch somewhere I can fetch it
I've put it ingit://xenbits.xen.org/people/ianc/osstest.git arm64-part1
That's without the last one to add the jobs themselves.
Quoted 2 lines
I will take a quick
look some time late on Saturday or on Sunday.
Thanks!