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-grub32 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>
---
 Makefile         |  4 ++--
 stubdom/Makefile | 13 +++++++++++++
 2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index 96d32cfd50..5b5cef3e49 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-grub32
 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-grub32
 endif
 
 .PHONY: tools/firmware/seabios-dir-force-update
diff --git a/stubdom/Makefile b/stubdom/Makefile
index 06aa69d8bc..b339ae701c 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-grub32
+ifneq ($(filter grub,$(STUBDOM_TARGETS)),)
+pv-grub32: pv-grub
+else
+pv-grub32:
+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-grub32: install-grub
+else
+install-grub32:
+endif
+
 install-c: c-stubdom
 
 install-caml: caml-stubdom
-- 
2.26.2

Juergen Gross writes ("[PATCH v2 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-grub32 target in stubdom/Makefile taking
> care of this situation.

I approve of this whole series, with one resrvation:

I think the name "pv-grub32" for this target is confusing.  It's not
really specifically 32-bit.  The difference between the targets
"pv-grub32" and "pv-grub" is that "pv-grub32" is unconditionally
built but might mean nothing; it has a conditional dependency on
"pv-grub" which is conditionally built but always implies the actual
build.

I don't think the suffix "32" really conveys this :-).

How about "pv-grub-maybe" ?  Or something.

You can put my ack on patches 2 and 3 right away.

Thanks,
Ian.

On 09.09.21 15:23, Ian Jackson wrote:
> Juergen Gross writes ("[PATCH v2 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-grub32 target in stubdom/Makefile taking
>> care of this situation.
> 
> I approve of this whole series, with one resrvation:
> 
> I think the name "pv-grub32" for this target is confusing.  It's not
> really specifically 32-bit.  The difference between the targets
> "pv-grub32" and "pv-grub" is that "pv-grub32" is unconditionally
> built but might mean nothing; it has a conditional dependency on
> "pv-grub" which is conditionally built but always implies the actual
> build.
> 
> I don't think the suffix "32" really conveys this :-).
> 
> How about "pv-grub-maybe" ?  Or something.

What about "pv-grub-if-enabled"?

And could that be done when committing, or should I send another round?

> 
> You can put my ack on patches 2 and 3 right away.

Thanks,


Juergen

Juergen Gross writes ("Re: [PATCH v2 1/3] stubdom: fix build with disabled pv-grub"):
> On 09.09.21 15:23, Ian Jackson wrote:
> > How about "pv-grub-maybe" ?  Or something.
> 
> What about "pv-grub-if-enabled"?

Fine by me.

> And could that be done when committing, or should I send another round?

Please do send another round (sorry).

Thanks,
Ian.

On 09.09.21 18:08, Ian Jackson wrote:
> Juergen Gross writes ("Re: [PATCH v2 1/3] stubdom: fix build with disabled pv-grub"):
>> On 09.09.21 15:23, Ian Jackson wrote:
>>> How about "pv-grub-maybe" ?  Or something.
>>
>> What about "pv-grub-if-enabled"?
> 
> Fine by me.
> 
>> And could that be done when committing, or should I send another round?
> 
> Please do send another round (sorry).

NP.

BTW, you probably want to modify OSStest to use configure with:

--enable-pv-grub --enable-qemu-traditional

in order to not let the tests fail (applies to x86 only, of course).


Juergen

Juergen Gross writes ("Re: [PATCH v2 1/3] stubdom: fix build with disabled pv-grub"):
> BTW, you probably want to modify OSStest to use configure with:
> 
> --enable-pv-grub --enable-qemu-traditional
> 
> in order to not let the tests fail (applies to x86 only, of course).

I think it might be better to disable those tests.  What do people
think ?

Ian.

On 10.09.21 17:32, Ian Jackson wrote:
> Juergen Gross writes ("Re: [PATCH v2 1/3] stubdom: fix build with disabled pv-grub"):
>> BTW, you probably want to modify OSStest to use configure with:
>>
>> --enable-pv-grub --enable-qemu-traditional
>>
>> in order to not let the tests fail (applies to x86 only, of course).
> 
> I think it might be better to disable those tests.  What do people
> think ?

Disabling pv-grub tests is okay (I think it happened already, right?).

Disabling qemu-trad tests with qemu running in dom0 is fine, too, IMO.

Disabling the stubdom tests is much more concerning, as there is quite
some code in the tools which would be untested then.


Juergen