All of lore.kernel.org
 help / color / mirror / Atom feed
* Build break with patch for "qemuboot, xen-image-minimal: enable runqemu for qemuarm64 Xen images"
@ 2021-08-01 15:36 Jon Mason
  2021-08-02  1:03 ` [meta-virtualization] " Christopher Clark
  0 siblings, 1 reply; 4+ messages in thread
From: Jon Mason @ 2021-08-01 15:36 UTC (permalink / raw)
  To: Christopher Clark, Bruce Ashfield; +Cc: meta-virtualization

I'm building xen-image-minimal for gem5-arm64 machine (in the meta-arm
layer) and the recent patch to add qemuarm64 support is breaking my
builds.  The patch in question is:

19347a7c4e4c qemuboot, xen-image-minimal: enable runqemu for qemuarm64
Xen images

You can see an example of the breakage here:
https://gitlab.com/jonmason00/meta-arm/-/jobs/1468242014

The problematic line is
diff --git a/recipes-extended/images/xen-image-minimal.bb
b/recipes-extended/images/xen-image-minimal.bb
index 6733801cca5f..ca6d26836c42 100644
--- a/recipes-extended/images/xen-image-minimal.bb
+++ b/recipes-extended/images/xen-image-minimal.bb
@@ -31,7 +31,7 @@ XEN_PCIBACK_MODULE_x86-64 = "kernel-module-xen-pciback"

 LICENSE = "MIT"

-inherit core-image
+inherit core-image qemuboot-xen-defaults qemuboot-xen-dtb

Reverting this line "fixes" my problem.  It seems odd to add qemu
stuff for machines that don't need it.  Is it right to add qemu stuff
to an image.bb?


Thanks,
Jon

^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [meta-virtualization] Build break with patch for "qemuboot, xen-image-minimal: enable runqemu for qemuarm64 Xen images"
  2021-08-01 15:36 Build break with patch for "qemuboot, xen-image-minimal: enable runqemu for qemuarm64 Xen images" Jon Mason
@ 2021-08-02  1:03 ` Christopher Clark
  2021-08-02 13:54   ` Jon Mason
  0 siblings, 1 reply; 4+ messages in thread
From: Christopher Clark @ 2021-08-02  1:03 UTC (permalink / raw)
  To: Jon Mason; +Cc: Christopher Clark, Bruce Ashfield, meta-virtualization

On Sun, Aug 1, 2021 at 8:36 AM Jon Mason <jdmason@kudzu.us> wrote:
>
> I'm building xen-image-minimal for gem5-arm64 machine (in the meta-arm
> layer) and the recent patch to add qemuarm64 support is breaking my
> builds.  The patch in question is:
>
> 19347a7c4e4c qemuboot, xen-image-minimal: enable runqemu for qemuarm64
> Xen images
>
> You can see an example of the breakage here:
> https://gitlab.com/jonmason00/meta-arm/-/jobs/1468242014

Hi Jon

I'm sorry that my patch caused trouble and thanks for sending your
report. I now understand the issue.

> The problematic line is
> diff --git a/recipes-extended/images/xen-image-minimal.bb
> b/recipes-extended/images/xen-image-minimal.bb
> index 6733801cca5f..ca6d26836c42 100644
> --- a/recipes-extended/images/xen-image-minimal.bb
> +++ b/recipes-extended/images/xen-image-minimal.bb
> @@ -31,7 +31,7 @@ XEN_PCIBACK_MODULE_x86-64 = "kernel-module-xen-pciback"
>
>  LICENSE = "MIT"
>
> -inherit core-image
> +inherit core-image qemuboot-xen-defaults qemuboot-xen-dtb
>
> Reverting this line "fixes" my problem.

Would you be able to try applying this patch instead? I believe it
will resolve the issue.

diff --git a/classes/qemuboot-xen-dtb.bbclass b/classes/qemuboot-xen-dtb.bbclass
index 08f9b02..2d37e91 100644
--- a/classes/qemuboot-xen-dtb.bbclass
+++ b/classes/qemuboot-xen-dtb.bbclass
@@ -176,7 +176,7 @@ do_write_xen_qemuboot_dtb() {
     # Not all architectures qemuboot with a device tree binary, so check
     # to see if one is needed. This allows this bbclass file to be used
     # in the same image recipe for multiple architectures.
-    if [ -n "${QB_DTB}" ] ; then
+    if [ -n "${QB_DTB}" ] && [ -n "${QB_SYSTEM_NAME}" ] ; then
         generate_xen_qemuboot_dtb
     fi
 }


> It seems odd to add qemu
> stuff for machines that don't need it.  Is it right to add qemu stuff
> to an image.bb?

I believe that it is reasonable to do so as it enables support for
testing the image (or images derived from it) even if the intended
final target is non-qemu hardware. I have been working on using this
qemu support to enable the OpenEmbedded QA framework to launch a Xen
image and execute standard and Xen-specific OEQA test cases within it,
eg. via: bitbake -c testimage xen-image-minimal
It should be a valuable capability for images that are built even for
non-qemu machine targets. You can also see within this layer that the
xvisor image recipe similarly chooses to include qemu-specific items.

thanks,

Christopher

^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [meta-virtualization] Build break with patch for "qemuboot, xen-image-minimal: enable runqemu for qemuarm64 Xen images"
  2021-08-02  1:03 ` [meta-virtualization] " Christopher Clark
@ 2021-08-02 13:54   ` Jon Mason
  2021-08-02 17:50     ` Christopher Clark
  0 siblings, 1 reply; 4+ messages in thread
From: Jon Mason @ 2021-08-02 13:54 UTC (permalink / raw)
  To: Christopher Clark; +Cc: Christopher Clark, Bruce Ashfield, meta-virtualization

On Sun, Aug 1, 2021 at 9:03 PM Christopher Clark
<christopher.w.clark@gmail.com> wrote:
>
> On Sun, Aug 1, 2021 at 8:36 AM Jon Mason <jdmason@kudzu.us> wrote:
> >
> > I'm building xen-image-minimal for gem5-arm64 machine (in the meta-arm
> > layer) and the recent patch to add qemuarm64 support is breaking my
> > builds.  The patch in question is:
> >
> > 19347a7c4e4c qemuboot, xen-image-minimal: enable runqemu for qemuarm64
> > Xen images
> >
> > You can see an example of the breakage here:
> > https://gitlab.com/jonmason00/meta-arm/-/jobs/1468242014
>
> Hi Jon
>
> I'm sorry that my patch caused trouble and thanks for sending your
> report. I now understand the issue.

It happens, and I appreciate your rapid response (on a Sunday!).  This
is the reason why we have our nightly Gitlab CI runs :)

>
> > The problematic line is
> > diff --git a/recipes-extended/images/xen-image-minimal.bb
> > b/recipes-extended/images/xen-image-minimal.bb
> > index 6733801cca5f..ca6d26836c42 100644
> > --- a/recipes-extended/images/xen-image-minimal.bb
> > +++ b/recipes-extended/images/xen-image-minimal.bb
> > @@ -31,7 +31,7 @@ XEN_PCIBACK_MODULE_x86-64 = "kernel-module-xen-pciback"
> >
> >  LICENSE = "MIT"
> >
> > -inherit core-image
> > +inherit core-image qemuboot-xen-defaults qemuboot-xen-dtb
> >
> > Reverting this line "fixes" my problem.
>
> Would you be able to try applying this patch instead? I believe it
> will resolve the issue.
>
> diff --git a/classes/qemuboot-xen-dtb.bbclass b/classes/qemuboot-xen-dtb.bbclass
> index 08f9b02..2d37e91 100644
> --- a/classes/qemuboot-xen-dtb.bbclass
> +++ b/classes/qemuboot-xen-dtb.bbclass
> @@ -176,7 +176,7 @@ do_write_xen_qemuboot_dtb() {
>      # Not all architectures qemuboot with a device tree binary, so check
>      # to see if one is needed. This allows this bbclass file to be used
>      # in the same image recipe for multiple architectures.
> -    if [ -n "${QB_DTB}" ] ; then
> +    if [ -n "${QB_DTB}" ] && [ -n "${QB_SYSTEM_NAME}" ] ; then
>          generate_xen_qemuboot_dtb
>      fi
>  }

This does indeed allow it to compile without issue.  Please push this
as soon as possible.

>
> > It seems odd to add qemu
> > stuff for machines that don't need it.  Is it right to add qemu stuff
> > to an image.bb?
>
> I believe that it is reasonable to do so as it enables support for
> testing the image (or images derived from it) even if the intended
> final target is non-qemu hardware. I have been working on using this
> qemu support to enable the OpenEmbedded QA framework to launch a Xen
> image and execute standard and Xen-specific OEQA test cases within it,
> eg. via: bitbake -c testimage xen-image-minimal
> It should be a valuable capability for images that are built even for
> non-qemu machine targets. You can also see within this layer that the
> xvisor image recipe similarly chooses to include qemu-specific items.

Poor wording on my part.  I'm not saying QEMU has no value in testing,
I was trying to say that I don't see similar things in other layers
that use qemu (lazily looking at poky as my example).  This could very
well be the right way of doing it, and I'm just ignorant of it.

All of that being said, I am interested in what you are doing here.  I
think running CI on qemu xen arm64 as part of our development process
could be very beneficial.  In our current setup, we're running
testimage on qemu machines.  Do you have anything similar planned for
this machine?

Thanks,
Jon

>
> thanks,
>
> Christopher

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [meta-virtualization] Build break with patch for "qemuboot, xen-image-minimal: enable runqemu for qemuarm64 Xen images"
  2021-08-02 13:54   ` Jon Mason
@ 2021-08-02 17:50     ` Christopher Clark
  0 siblings, 0 replies; 4+ messages in thread
From: Christopher Clark @ 2021-08-02 17:50 UTC (permalink / raw)
  To: Jon Mason; +Cc: Christopher Clark, Bruce Ashfield, meta-virtualization

On Mon, Aug 2, 2021 at 6:54 AM Jon Mason <jdmason@kudzu.us> wrote:
>
> On Sun, Aug 1, 2021 at 9:03 PM Christopher Clark
> <christopher.w.clark@gmail.com> wrote:
> >
> > On Sun, Aug 1, 2021 at 8:36 AM Jon Mason <jdmason@kudzu.us> wrote:
> > >
> > > I'm building xen-image-minimal for gem5-arm64 machine (in the meta-arm
> > > layer) and the recent patch to add qemuarm64 support is breaking my
> > > builds.  The patch in question is:
> > >
> > > 19347a7c4e4c qemuboot, xen-image-minimal: enable runqemu for qemuarm64
> > > Xen images
> > >
> > > You can see an example of the breakage here:
> > > https://gitlab.com/jonmason00/meta-arm/-/jobs/1468242014
> >
> > Hi Jon
> >
> > I'm sorry that my patch caused trouble and thanks for sending your
> > report. I now understand the issue.
>
> It happens, and I appreciate your rapid response (on a Sunday!).  This
> is the reason why we have our nightly Gitlab CI runs :)
>
> >
> > > The problematic line is
> > > diff --git a/recipes-extended/images/xen-image-minimal.bb
> > > b/recipes-extended/images/xen-image-minimal.bb
> > > index 6733801cca5f..ca6d26836c42 100644
> > > --- a/recipes-extended/images/xen-image-minimal.bb
> > > +++ b/recipes-extended/images/xen-image-minimal.bb
> > > @@ -31,7 +31,7 @@ XEN_PCIBACK_MODULE_x86-64 = "kernel-module-xen-pciback"
> > >
> > >  LICENSE = "MIT"
> > >
> > > -inherit core-image
> > > +inherit core-image qemuboot-xen-defaults qemuboot-xen-dtb
> > >
> > > Reverting this line "fixes" my problem.
> >
> > Would you be able to try applying this patch instead? I believe it
> > will resolve the issue.
> >
> > diff --git a/classes/qemuboot-xen-dtb.bbclass b/classes/qemuboot-xen-dtb.bbclass
> > index 08f9b02..2d37e91 100644
> > --- a/classes/qemuboot-xen-dtb.bbclass
> > +++ b/classes/qemuboot-xen-dtb.bbclass
> > @@ -176,7 +176,7 @@ do_write_xen_qemuboot_dtb() {
> >      # Not all architectures qemuboot with a device tree binary, so check
> >      # to see if one is needed. This allows this bbclass file to be used
> >      # in the same image recipe for multiple architectures.
> > -    if [ -n "${QB_DTB}" ] ; then
> > +    if [ -n "${QB_DTB}" ] && [ -n "${QB_SYSTEM_NAME}" ] ; then
> >          generate_xen_qemuboot_dtb
> >      fi
> >  }
>
> This does indeed allow it to compile without issue.  Please push this
> as soon as possible.

Excellent, thanks!

>
> >
> > > It seems odd to add qemu
> > > stuff for machines that don't need it.  Is it right to add qemu stuff
> > > to an image.bb?
> >
> > I believe that it is reasonable to do so as it enables support for
> > testing the image (or images derived from it) even if the intended
> > final target is non-qemu hardware. I have been working on using this
> > qemu support to enable the OpenEmbedded QA framework to launch a Xen
> > image and execute standard and Xen-specific OEQA test cases within it,
> > eg. via: bitbake -c testimage xen-image-minimal
> > It should be a valuable capability for images that are built even for
> > non-qemu machine targets. You can also see within this layer that the
> > xvisor image recipe similarly chooses to include qemu-specific items.
>
> Poor wording on my part.  I'm not saying QEMU has no value in testing,
> I was trying to say that I don't see similar things in other layers
> that use qemu (lazily looking at poky as my example).  This could very
> well be the right way of doing it, and I'm just ignorant of it.

I think the default OE qemu settings are OK for most images so no
adjustments are needed, but those that include a hypervisor, or at
least a type-1 hypervisor, may require some tuning of the settings to
enable a successful boot. It gets even more complicated for Xen since
the x86 and Arm platform boot configurations are currently rather
different.

> All of that being said, I am interested in what you are doing here.  I
> think running CI on qemu xen arm64 as part of our development process
> could be very beneficial.  In our current setup, we're running
> testimage on qemu machines.  Do you have anything similar planned for
> this machine?

I've recently added recipes for the Xen Test Framework to
meta-virtualization as preparation towards enabling that to run in CI
with OEQA (ie. testimage). XTF is currently only for x86 platforms but
I am aware of development efforts to enable running XTF on Arm too, so
it should be useful to you when that lands. I have been working on the
integration needed for XTF to run as an OEQA test case and I do have a
working early version, but doing that work has surfaced some
challenges with the Xen toolstack that I need to resolve first, so
that's my current focus.

I'm very happy to hear that you're already running CI on the Xen
recipes and image - please do report any issues that you find.

best,

Christopher

>
> Thanks,
> Jon
>
> >
> > thanks,
> >
> > Christopher

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2021-08-02 17:50 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-08-01 15:36 Build break with patch for "qemuboot, xen-image-minimal: enable runqemu for qemuarm64 Xen images" Jon Mason
2021-08-02  1:03 ` [meta-virtualization] " Christopher Clark
2021-08-02 13:54   ` Jon Mason
2021-08-02 17:50     ` Christopher Clark

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.