[PATCH v3 0/3] disable building of pv-grub and qemu-trad per default

[PATCH v3 0/3] disable building of pv-grub and qemu-trad per default

[Juergen Gross]

This is a first step of deprecating pv-grub and qemu-trad including
ioemu-stubdom. Switch the default to not building it.

Changes in V3:
- rename pv-grub32 make target

Changes in V2:
- new patch 3
- added CHANGELOG.md entry in patch 2

Juergen Gross (3):
  stubdom: fix build with disabled pv-grub
  stubdom: disable building pv-grub
  tools: disable building qemu-trad per default

 CHANGELOG.md         |  5 +++++
 Makefile             |  4 ++--
 stubdom/Makefile     | 13 +++++++++++++
 stubdom/configure    | 16 ++--------------
 stubdom/configure.ac | 10 ++--------
 tools/configure      | 17 ++---------------
 tools/configure.ac   | 13 +------------
 7 files changed, 27 insertions(+), 51 deletions(-)

-- 
2.26.2

[PATCH v3 1/3] stubdom: fix build with disabled pv-grub

[Juergen Gross]

Today the build will fail if --disable-pv-grub as a parameter of
configure, as the main Makefile will unconditionally try to build a
32-bit pv-grub stubdom.

Fix that by introducing a pv-grub-if-enabled target in
stubdom/Makefile taking care of this situation.

Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
--
V3:
- rename pv-grub32 target (Ian Jackson)
---
 Makefile         |  4 ++--
 stubdom/Makefile | 13 +++++++++++++
 2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index 96d32cfd50..346d73a0dc 100644
--- a/Makefile
+++ b/Makefile
@@ -72,7 +72,7 @@ build-tools-oxenstored: build-tools-public-headers
 build-stubdom: mini-os-dir build-tools-public-headers
 	$(MAKE) -C stubdom build
 ifeq (x86_64,$(XEN_TARGET_ARCH))
-	XEN_TARGET_ARCH=x86_32 $(MAKE) -C stubdom pv-grub
+	XEN_TARGET_ARCH=x86_32 $(MAKE) -C stubdom pv-grub-if-enabled
 endif
 
 .PHONY: build-docs
@@ -143,7 +143,7 @@ install-tools: install-tools-public-headers
 install-stubdom: mini-os-dir install-tools
 	$(MAKE) -C stubdom install
 ifeq (x86_64,$(XEN_TARGET_ARCH))
-	XEN_TARGET_ARCH=x86_32 $(MAKE) -C stubdom install-grub
+	XEN_TARGET_ARCH=x86_32 $(MAKE) -C stubdom install-grub-if-enabled
 endif
 
 .PHONY: tools/firmware/seabios-dir-force-update
diff --git a/stubdom/Makefile b/stubdom/Makefile
index 06aa69d8bc..ccfcf5b75f 100644
--- a/stubdom/Makefile
+++ b/stubdom/Makefile
@@ -531,6 +531,13 @@ vtpmmgr-stubdom: mini-os-$(XEN_TARGET_ARCH)-vtpmmgr vtpmmgr
 pv-grub: mini-os-$(XEN_TARGET_ARCH)-grub libxenguest grub
 	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/grub/minios.cfg" $(MAKE) DESTDIR= -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< APP_OBJS=$(CURDIR)/grub-$(XEN_TARGET_ARCH)/main.a
 
+.PHONY: pv-grub-if-enabled
+ifneq ($(filter grub,$(STUBDOM_TARGETS)),)
+pv-grub-if-enabled: pv-grub
+else
+pv-grub-if-enabled:
+endif
+
 .PHONY: xenstore-stubdom
 xenstore-stubdom: mini-os-$(XEN_TARGET_ARCH)-xenstore libxenguest xenstore
 	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/xenstore-minios.cfg" $(MAKE) DESTDIR= -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< APP_OBJS=$(CURDIR)/xenstore/xenstored.a
@@ -560,6 +567,12 @@ install-grub: pv-grub
 	$(INSTALL_DIR) "$(DESTDIR)$(XENFIRMWAREDIR)"
 	$(INSTALL_DATA) mini-os-$(XEN_TARGET_ARCH)-grub/mini-os.gz "$(DESTDIR)$(XENFIRMWAREDIR)/pv-grub-$(XEN_TARGET_ARCH).gz"
 
+ifneq ($(filter grub,$(STUBDOM_TARGETS)),)
+install-grub-if-enabled: install-grub
+else
+install-grub-if-enabled:
+endif
+
 install-c: c-stubdom
 
 install-caml: caml-stubdom
-- 
2.26.2

Re: [PATCH v3 1/3] stubdom: fix build with disabled pv-grub

[Ian Jackson]

Juergen Gross writes ("[PATCH v3 1/3] stubdom: fix build with disabled pv-grub"):
> Today the build will fail if --disable-pv-grub as a parameter of
> configure, as the main Makefile will unconditionally try to build a
> 32-bit pv-grub stubdom.
> 
> Fix that by introducing a pv-grub-if-enabled target in
> stubdom/Makefile taking care of this situation.
> 
> Signed-off-by: Juergen Gross <jgross@suse.com>
> Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

Reviewed-by: Ian Jackson <iwj@xenproject.org>

[PATCH v3 2/3] stubdom: disable building pv-grub

[Juergen Gross]

The stubdom based pv-grub is using a very outdated version of grub
(0.97) and should not be used any longer. Mainline grub has support for
PV guests for a long time now, so that should be used as a boot loader
of a PV domain.

So disable building pv-grub per default. In case someone really wants
to continue using it he/she can still use a pv-grub binary from an older
Xen version or manually enable building it via:

  configure --enable-pv-grub

Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Acked-by: Ian Jackson <iwj@xenproject.org>
---
V2:
- add CHANGELOG.md entry (Jan Beulich)
---
 CHANGELOG.md         | 2 ++
 stubdom/configure    | 8 ++------
 stubdom/configure.ac | 2 +-
 3 files changed, 5 insertions(+), 7 deletions(-)

diff --git a/CHANGELOG.md b/CHANGELOG.md
index 22cfdb4298..e7107ac3de 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -16,6 +16,8 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
    appearing in 4.12.2 and 4.11.4). Prior (4.13...4.15-like) behavior can be arranged for
    either by enabling the IOMMU_QUARANTINE_SCRATCH_PAGE setting at build (configuration) time
    or by passing "iommu=quarantine=scratch-page" on the hypervisor command line.
+ - pv-grub stubdoms will no longer be built per default. In order to be able to use pv-grub
+   configure needs to be called with "--enable-pv-grub" as parameter.
 
 ## [4.15.0 UNRELEASED](https://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=RELEASE-4.15.0) - TBD
 
diff --git a/stubdom/configure b/stubdom/configure
index aa48df986d..df31532abb 100755
--- a/stubdom/configure
+++ b/stubdom/configure
@@ -1342,7 +1342,7 @@ Optional Features:
   --enable-ioemu-stubdom  Build and install ioemu-stubdom
   --enable-c-stubdom      Build and install c-stubdom (default is DISABLED)
   --enable-caml-stubdom   Build and install caml-stubdom (default is DISABLED)
-  --disable-pv-grub       Build and install pv-grub (default is ENABLED)
+  --enable-pv-grub        Build and install pv-grub (default is DISABLED)
   --disable-xenstore-stubdom
                           Build and install xenstore-stubdom (default is
                           ENABLED)
@@ -2129,11 +2129,7 @@ fi
 else
 
 
-grub=y
-STUBDOM_TARGETS="$STUBDOM_TARGETS grub"
-STUBDOM_BUILD="$STUBDOM_BUILD pv-grub"
-STUBDOM_INSTALL="$STUBDOM_INSTALL install-grub"
-STUBDOM_UNINSTALL="$STUBDOM_UNINSTALL install-grub"
+grub=n
 
 
 fi
diff --git a/stubdom/configure.ac b/stubdom/configure.ac
index bd6f765929..a07a1edae5 100644
--- a/stubdom/configure.ac
+++ b/stubdom/configure.ac
@@ -21,7 +21,7 @@ m4_include([../m4/fetcher.m4])
 AX_STUBDOM_CONDITIONAL([ioemu-stubdom], [ioemu])
 AX_STUBDOM_DEFAULT_DISABLE([c-stubdom], [c])
 AX_STUBDOM_DEFAULT_DISABLE([caml-stubdom], [caml])
-AX_STUBDOM_DEFAULT_ENABLE([pv-grub], [grub])
+AX_STUBDOM_DEFAULT_DISABLE([pv-grub], [grub])
 AX_STUBDOM_DEFAULT_ENABLE([xenstore-stubdom], [xenstore])
 AX_STUBDOM_DEFAULT_ENABLE([xenstorepvh-stubdom], [xenstorepvh])
 AX_STUBDOM_CONDITIONAL([vtpm-stubdom], [vtpm])
-- 
2.26.2

[PATCH v3 3/3] tools: disable building qemu-trad per default

[Juergen Gross]

Using qemu-traditional as device model is deprecated for some time now.

So change the default for building it to "disable". This will affect
ioemu-stubdom, too, as there is a direct dependency between the two.

Today it is possible to use a PVH/HVM Linux-based stubdom as device
model. Additionally using ioemu-stubdom isn't really helping for
security, as it requires to run a very old and potentially buggy qemu
version in a PV domain. This is adding probably more security problems
than it is removing by using a stubdom.

Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Acked-by: Ian Jackson <iwj@xenproject.org>
---
V2:
- new patch
---
 CHANGELOG.md         |  3 +++
 stubdom/configure    |  8 --------
 stubdom/configure.ac |  8 +-------
 tools/configure      | 17 ++---------------
 tools/configure.ac   | 13 +------------
 5 files changed, 7 insertions(+), 42 deletions(-)

diff --git a/CHANGELOG.md b/CHANGELOG.md
index e7107ac3de..e5ab49e779 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -18,6 +18,9 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
    or by passing "iommu=quarantine=scratch-page" on the hypervisor command line.
  - pv-grub stubdoms will no longer be built per default. In order to be able to use pv-grub
    configure needs to be called with "--enable-pv-grub" as parameter.
+ - qemu-traditional based device models (both, qemu-traditional and ioemu-stubdom) will
+   no longer be built per default. In order to be able to use those, configure needs to
+   be called with "--enable-qemu-traditional" as parameter.
 
 ## [4.15.0 UNRELEASED](https://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=RELEASE-4.15.0) - TBD
 
diff --git a/stubdom/configure b/stubdom/configure
index df31532abb..07b709f998 100755
--- a/stubdom/configure
+++ b/stubdom/configure
@@ -2286,14 +2286,6 @@ fi
 # Check whether --enable-qemu-traditional was given.
 if test "${enable_qemu_traditional+set}" = set; then :
   enableval=$enable_qemu_traditional;
-else
-
-    case "$host_cpu" in
-        i[3456]86|x86_64)
-           enable_qemu_traditional="yes";;
-        *) enable_qemu_traditional="no";;
-    esac
-
 fi
 
 if test "x$enable_qemu_traditional" = "xyes"; then :
diff --git a/stubdom/configure.ac b/stubdom/configure.ac
index a07a1edae5..e20d99edac 100644
--- a/stubdom/configure.ac
+++ b/stubdom/configure.ac
@@ -27,13 +27,7 @@ AX_STUBDOM_DEFAULT_ENABLE([xenstorepvh-stubdom], [xenstorepvh])
 AX_STUBDOM_CONDITIONAL([vtpm-stubdom], [vtpm])
 AX_STUBDOM_CONDITIONAL([vtpmmgr-stubdom], [vtpmmgr])
 
-AC_ARG_ENABLE([qemu-traditional],,,[
-    case "$host_cpu" in
-        i[[3456]]86|x86_64)
-           enable_qemu_traditional="yes";;
-        *) enable_qemu_traditional="no";;
-    esac
-])
+AC_ARG_ENABLE([qemu-traditional])
 AS_IF([test "x$enable_qemu_traditional" = "xyes"], [
     qemu_traditional=y],[
     qemu_traditional=n
diff --git a/tools/configure b/tools/configure
index 33814b24b3..8bf8fe75b8 100755
--- a/tools/configure
+++ b/tools/configure
@@ -1502,8 +1502,8 @@ Optional Features:
   --disable-seabios       Disable SeaBIOS (default is ENABLED)
   --disable-golang        Disable Go tools (default is ENABLED)
   --enable-qemu-traditional
-                          Enable qemu traditional device model, (DEFAULT is on
-                          for Linux or NetBSD x86, otherwise off)
+                          Enable qemu traditional device model, (DEFAULT is
+                          off)
   --enable-rombios        Enable ROMBIOS, (DEFAULT is on if qemu-traditional
                           is enabled, otherwise off)
   --disable-ipxe          Enable in-tree IPXE, (DEFAULT is on if rombios is
@@ -4287,19 +4287,6 @@ LINUX_BACKEND_MODULES="`eval echo $LINUX_BACKEND_MODULES`"
 # Check whether --enable-qemu-traditional was given.
 if test "${enable_qemu_traditional+set}" = set; then :
   enableval=$enable_qemu_traditional;
-else
-
-    case "$host_cpu" in
-        i[3456]86|x86_64)
-           enable_qemu_traditional="yes";;
-        *) enable_qemu_traditional="no";;
-    esac
-    case "$host_os" in
-        freebsd*)
-           enable_qemu_traditional="no";;
-    esac
-
-
 fi
 
 if test "x$enable_qemu_traditional" = "xyes"; then :
diff --git a/tools/configure.ac b/tools/configure.ac
index 6414fcbb44..a713fd34d6 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -120,18 +120,7 @@ AC_SUBST(LINUX_BACKEND_MODULES)
 
 AC_ARG_ENABLE([qemu-traditional],
     AS_HELP_STRING([--enable-qemu-traditional],
-                   [Enable qemu traditional device model, (DEFAULT is on for Linux or NetBSD x86, otherwise off)]),,[
-    case "$host_cpu" in
-        i[[3456]]86|x86_64)
-           enable_qemu_traditional="yes";;
-        *) enable_qemu_traditional="no";;
-    esac
-    case "$host_os" in
-        freebsd*)
-           enable_qemu_traditional="no";;
-    esac
-
-])
+                   [Enable qemu traditional device model, (DEFAULT is off)]))
 AS_IF([test "x$enable_qemu_traditional" = "xyes"], [
 AC_DEFINE([HAVE_QEMU_TRADITIONAL], [1], [Qemu traditional enabled])
     qemu_traditional=y],[
-- 
2.26.2

Re: [PATCH v3 3/3] tools: disable building qemu-trad per default

[Ian Jackson]

Juergen Gross writes ("[PATCH v3 3/3] tools: disable building qemu-trad per default"):
> Using qemu-traditional as device model is deprecated for some time now.
> 
> So change the default for building it to "disable". This will affect
> ioemu-stubdom, too, as there is a direct dependency between the two.
> 
> Today it is possible to use a PVH/HVM Linux-based stubdom as device
> model. Additionally using ioemu-stubdom isn't really helping for
> security, as it requires to run a very old and potentially buggy qemu
> version in a PV domain. This is adding probably more security problems
> than it is removing by using a stubdom.
> 
> Signed-off-by: Juergen Gross <jgross@suse.com>
> Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
> Acked-by: Ian Jackson <iwj@xenproject.org>

Now that the relevant osstest patches are in and stable, I revisited
this.  The downside risk to the release is very modest.  It might
cause some temporary test breakage but is very easily reverted.

The upside is that this will accelerate the total removal of qemu-trad
by about one release cycle.  That is highly desirable.

Release-Acked-by: Ian Jackson <iwj@xenproject.org>

And pushed to staging.

Ian.

Re: [PATCH v3 3/3] tools: disable building qemu-trad per default

[Ian Jackson]

Ian Jackson writes ("Re: [PATCH v3 3/3] tools: disable building qemu-trad per default"):
> Juergen Gross writes ("[PATCH v3 3/3] tools: disable building qemu-trad per default"):
> > Using qemu-traditional as device model is deprecated for some time now.
> > 
> > So change the default for building it to "disable". This will affect
> > ioemu-stubdom, too, as there is a direct dependency between the two.
> > 
> > Today it is possible to use a PVH/HVM Linux-based stubdom as device
> > model. Additionally using ioemu-stubdom isn't really helping for
> > security, as it requires to run a very old and potentially buggy qemu
> > version in a PV domain. This is adding probably more security problems
> > than it is removing by using a stubdom.
> 
> Now that the relevant osstest patches are in and stable, I revisited
> this.  The downside risk to the release is very modest.  It might
> cause some temporary test breakage but is very easily reverted.
...
> And pushed to staging.

Unfortunately this broke the gitlab CI:

https://gitlab.com/xen-project/people/andyhhp/xen/-/jobs/1743723306

  === configuring in tools (/builds/xen-project/people/andyhhp/xen/tools)
  configure: running /bin/sh ./configure --disable-option-checking '--prefix=/usr/local'  '--enable-docs' '--with-system-seabios=/usr/share/seabios/bios.bin' '--with-system-ipxe=/usr/lib/ipxe/ipxe.pxe' '--disable-stubdom' '--with-extra-qemuu-configure-args="--disable-werror"' '--with-system-seabios=/bin/false' --cache-file=/dev/null --srcdir=.
  configure: WARNING: Setting CC, CFLAGS, LDFLAGS, LIBS, CPPFLAGS or CPP is not recommended, use PREPEND_INCLUDES, PREPEND_LIB, APPEND_INCLUDES and APPEND_LIB instead when possible.
  checking build system type... x86_64-pc-linux-musl
  ...
  checking for _FILE_OFFSET_BITS value needed for large files... no
  configure: error: Rombios is required to use IPXE
  configure: error: ./configure failed for tools

The configure arguments look coherent so this is surely a bug in the
configure script.

Looking at the code, it seems that there is code to enable rombios if
$enable_qemu_traditional, but nothing for ipxe.  This seems like a
bug, which was presumably masked by qemu-trad being enabled by
default.

With my RM hat on: Unfortunately I think this means this patch needs
to be reverted right away, at least for now, since it is causing a
regression.  I will do that now.

I would be open to reapplying it after the default for rombios is made
to depend on ipxe too, and ideally if we can see that the CI is happy
with the branch.

> The upside is that this will accelerate the total removal of qemu-trad
> by about one release cycle.  That is highly desirable.

So FTAOD although I am reverting this now, I am still in favour of it.

Thanks,
Ian.

Re: [PATCH v3 0/3] disable building of pv-grub and qemu-trad per default

[Ian Jackson]

Juergen Gross writes ("[PATCH v3 0/3] disable building of pv-grub and qemu-trad per default"):
> This is a first step of deprecating pv-grub and qemu-trad including
> ioemu-stubdom. Switch the default to not building it.

This is now fully acked.  But can we wait with committing it until we
have a decision about whether to (a) have osstest explicitly enable
the pv-grub and qemu-trad builds (b) have osstest stop testing these
configurations ?

Ian.

Re: [PATCH v3 0/3] disable building of pv-grub and qemu-trad per default

[Juergen Gross]

[-- Attachment #1.1.1: Type: text/plain, Size: 663 bytes --]

On 10.09.21 17:34, Ian Jackson wrote:
> Juergen Gross writes ("[PATCH v3 0/3] disable building of pv-grub and qemu-trad per default"):
>> This is a first step of deprecating pv-grub and qemu-trad including
>> ioemu-stubdom. Switch the default to not building it.
> 
> This is now fully acked.  But can we wait with committing it until we
> have a decision about whether to (a) have osstest explicitly enable
> the pv-grub and qemu-trad builds (b) have osstest stop testing these
> configurations ?

Any decisions made?

FWIW I'd be fine dropping pv-grub builds and tests in OSStets, but I'd
rather keep testing qemu-trad stubdom tests.


Juergen

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3135 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

Re: [PATCH v3 0/3] disable building of pv-grub and qemu-trad per default

[Ian Jackson]

Juergen Gross writes ("Re: [PATCH v3 0/3] disable building of pv-grub and qemu-trad per default"):
> On 10.09.21 17:34, Ian Jackson wrote:
> > Juergen Gross writes ("[PATCH v3 0/3] disable building of pv-grub and qemu-trad per default"):
> >> This is a first step of deprecating pv-grub and qemu-trad including
> >> ioemu-stubdom. Switch the default to not building it.
> > 
> > This is now fully acked.  But can we wait with committing it until we
> > have a decision about whether to (a) have osstest explicitly enable
> > the pv-grub and qemu-trad builds (b) have osstest stop testing these
> > configurations ?
> 
> Any decisions made?

No-one seems to have had any opinions.   I'll take ...

> FWIW I'd be fine dropping pv-grub builds and tests in OSStets, but I'd
> rather keep testing qemu-trad stubdom tests.

... that as a proposal :-).  think that is probably the right tradeoff.

I think that means that means we need osstest patches to edit
make-flight and ts-xen-build which

 * Explictly enables stubdom qemu build
 * Drops the pv-grub tests

and those need to go in first.

With my RM hat on, I think those changes to osstest may need a release
ack since they have missed the LPD, but I will grant such an ack.

As for the patches themselves, I may get to that tomorrow, but
contributions would be very welcome.

Thanks,
Ian.

Re: [PATCH v3 0/3] disable building of pv-grub and qemu-trad per default

[Juergen Gross]

[-- Attachment #1.1.1: Type: text/plain, Size: 1290 bytes --]

On 27.09.21 16:43, Ian Jackson wrote:
> Juergen Gross writes ("Re: [PATCH v3 0/3] disable building of pv-grub and qemu-trad per default"):
>> On 10.09.21 17:34, Ian Jackson wrote:
>>> Juergen Gross writes ("[PATCH v3 0/3] disable building of pv-grub and qemu-trad per default"):
>>>> This is a first step of deprecating pv-grub and qemu-trad including
>>>> ioemu-stubdom. Switch the default to not building it.
>>>
>>> This is now fully acked.  But can we wait with committing it until we
>>> have a decision about whether to (a) have osstest explicitly enable
>>> the pv-grub and qemu-trad builds (b) have osstest stop testing these
>>> configurations ?
>>
>> Any decisions made?
> 
> No-one seems to have had any opinions.   I'll take ...
> 
>> FWIW I'd be fine dropping pv-grub builds and tests in OSStets, but I'd
>> rather keep testing qemu-trad stubdom tests.
> 
> ... that as a proposal :-).  think that is probably the right tradeoff.
> 
> I think that means that means we need osstest patches to edit
> make-flight and ts-xen-build which
> 
>   * Explictly enables stubdom qemu build
>   * Drops the pv-grub tests
> 
> and those need to go in first.

I believe patch 1 of my series could go in at any time, as it is just
fixing a bug.


Juergen


[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3135 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

Re: [PATCH v3 0/3] disable building of pv-grub and qemu-trad per default

[Ian Jackson]

Juergen Gross writes ("Re: [PATCH v3 0/3] disable building of pv-grub and qemu-trad per default"):
> I believe patch 1 of my series could go in at any time, as it is just
> fixing a bug.

Oh yes, indeed.  Done.

Ian.

Re: [PATCH v3 0/3] disable building of pv-grub and qemu-trad per default

[Ian Jackson]

I wrote (27th September):
> Juergen Gross writes ("Re: [PATCH v3 0/3] disable building of pv-grub and qemu-trad per default"):
> > On 10.09.21 17:34, Ian Jackson wrote:
> > > Juergen Gross writes ("[PATCH v3 0/3] disable building of pv-grub and qemu-trad per default"):
> > >> This is a first step of deprecating pv-grub and qemu-trad including
> > >> ioemu-stubdom. Switch the default to not building it.
> > > 
> > > This is now fully acked.  But can we wait with committing it until we
> > > have a decision about whether to (a) have osstest explicitly enable
> > > the pv-grub and qemu-trad builds (b) have osstest stop testing these
> > > configurations ?
> > 
> > Any decisions made?
> 
> No-one seems to have had any opinions.   I'll take ...
> 
> > FWIW I'd be fine dropping pv-grub builds and tests in OSStets, but I'd
> > rather keep testing qemu-trad stubdom tests.
> 
> ... that as a proposal :-).  think that is probably the right tradeoff.
> 
> I think that means that means we need osstest patches to edit
> make-flight and ts-xen-build which
> 
>  * Explictly enables stubdom qemu build
>  * Drops the pv-grub tests
> 
> and those need to go in first.
> 
> With my RM hat on, I think those changes to osstest may need a release
> ack since they have missed the LPD, but I will grant such an ack.
> 
> As for the patches themselves, I may get to that tomorrow, but
> contributions would be very welcome.

Evidently I didn't get to that "tomorrow".  But while checking up on
this with git-log -G I found osstest commit:

  8dee6e333622d830b7a9373989f63b526a85cd94
  make-flight: Drop pvgrub (pvgrub1) tests

I think this means
  [PATCH v3 2/3] stubdom: disable building pv-grub
from this series can go in immediately.

With my RM hat on: I think this reduces risk, overall.  There is some
risk of immediately build breakage but the patch could be readily
reverted.

Accordingly, patch 2/3 disabling pv-grub is
  Release-Acked-by: Ian Jackson <iwj@xenproject.org>

It also has my tools ack so I will commit it in a moment.

I think 3/3 is waiting for the osstest patch.  In principle with my RM
hat on I think these could go in but it would have to be very soon,
and the osstest change has to go in first.

Ian.