[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] fix qemu build with xen-4.18.0
From: |
Anthony PERARD |
Subject: |
Re: [PATCH] fix qemu build with xen-4.18.0 |
Date: |
Tue, 12 Dec 2023 14:19:57 +0000 |
On Fri, Dec 08, 2023 at 02:49:27PM -0800, Stefano Stabellini wrote:
> On Fri, 8 Dec 2023, Daniel P. Berrangé wrote:
> > On Thu, Dec 07, 2023 at 11:12:48PM +0000, Michael Young wrote:
> > > Builds of qemu-8.2.0rc2 with xen-4.18.0 are currently failing
> > > with errors like
> > > ../hw/arm/xen_arm.c:74:5: error: ‘GUEST_VIRTIO_MMIO_SPI_LAST’ undeclared
> > > (first use in this function)
> > > 74 | (GUEST_VIRTIO_MMIO_SPI_LAST - GUEST_VIRTIO_MMIO_SPI_FIRST)
> > > | ^~~~~~~~~~~~~~~~~~~~~~~~~~
> > >
> > > as there is an incorrect comparision in include/hw/xen/xen_native.h
> > > which means that settings like GUEST_VIRTIO_MMIO_SPI_LAST
> > > aren't being defined for xen-4.18.0
> >
> > The conditions in arch-arm.h for xen 4.18 show:
> >
> > $ cppi arch-arm.h | grep -E '(#.*if)|MMIO'
> > #ifndef __XEN_PUBLIC_ARCH_ARM_H__
> > # if defined(__XEN__) || defined(__XEN_TOOLS__) || defined(__GNUC__)
> > # endif
> > # ifndef __ASSEMBLY__
> > # if defined(__XEN__) || defined(__XEN_TOOLS__)
> > # if defined(__GNUC__) && !defined(__STRICT_ANSI__)
> > # endif
> > # endif /* __XEN__ || __XEN_TOOLS__ */
> > # endif
> > # if defined(__XEN__) || defined(__XEN_TOOLS__)
> > # define PSR_MODE_BIT 0x10U /* Set iff AArch32 */
> > /* Virtio MMIO mappings */
> > # define GUEST_VIRTIO_MMIO_BASE xen_mk_ullong(0x02000000)
> > # define GUEST_VIRTIO_MMIO_SIZE xen_mk_ullong(0x00100000)
> > # define GUEST_VIRTIO_MMIO_SPI_FIRST 33
> > # define GUEST_VIRTIO_MMIO_SPI_LAST 43
> > # endif
> > # ifndef __ASSEMBLY__
> > # endif
> > #endif /* __XEN_PUBLIC_ARCH_ARM_H__ */
> >
> > So the MMIO constants are available if __XEN__ or __XEN_TOOLS__
> > are defined. This is no different to the condition that was
> > present in Xen 4.17.
> >
> > What you didn't mention was that the Fedora build failure is
> > seen on an x86_64 host, when building the aarch64 target QEMU,
> > and I think this is the key issue.
>
> Hi Daniel, thanks for looking into it.
>
> - you are building on a x86_64 host
> - the target is aarch64
> - the target is the aarch64 Xen PVH machine (xen_arm.c)
>
> But is the resulting QEMU binary expected to be an x86 binary? Or are
> you cross compiling ARM binaries on a x86 host?
>
> In other word, is the resulting QEMU binary expected to run on ARM or
> x86?
>
>
> > Are we expecting to build Xen support for non-arch native QEMU
> > system binaries or not ?
>
> The ARM xenpvh machine (xen_arm.c) is meant to work with Xen on ARM, not
> Xen on x86. So this is only expected to work if you are
> cross-compiling. But you can cross-compile both Xen and QEMU, and I am
> pretty sure that Yocto is able to build Xen, Xen userspace tools, and
> QEMU for Xen/ARM on an x86 host today.
>
>
> > The constants are defined in arch-arm.h, which is only included
> > under:
> >
> > #if defined(__i386__) || defined(__x86_64__)
> > #include "arch-x86/xen.h"
> > #elif defined(__arm__) || defined (__aarch64__)
> > #include "arch-arm.h"
> > #else
> > #error "Unsupported architecture"
> > #endif
> >
> >
> > When we are building on an x86_64 host, we not going to get
> > arch-arm.h included, even if we're trying to build the aarch64
> > system emulator.
> >
> > I don't know how this is supposed to work ?
>
> It looks like a host vs. target architecture mismatch: the #if defined
> (__aarch64__) check should pass I think.
Building qemu with something like:
./configure --enable-xen --cpu=x86_64
used to work. Can we fix that? It still works with v8.1.0.
At least, it works on x86, I never really try to build qemu for arm.
Notice that there's no "--target-list" on the configure command line.
I don't know if --cpu is useful here.
Looks like the first commit where the build doesn't work is
7899f6589b78 ("xen_arm: Add virtual PCIe host bridge support").
Could we get that fixed?
I'm sure distribution will appreciate to be able to build a single qemu
package for xen and other, rather than having a dedicated qemu-xen
package.
Cheers,
--
Anthony PERARD
- [PATCH] fix qemu build with xen-4.18.0, Michael Young, 2023/12/07
- Re: [PATCH] fix qemu build with xen-4.18.0, Richard W.M. Jones, 2023/12/08
- Re: [PATCH] fix qemu build with xen-4.18.0, Daniel P . Berrangé, 2023/12/08
- Re: [PATCH] fix qemu build with xen-4.18.0, Peter Maydell, 2023/12/08
- Re: [PATCH] fix qemu build with xen-4.18.0, Stefano Stabellini, 2023/12/08
- Re: [PATCH] fix qemu build with xen-4.18.0,
Anthony PERARD <=
- Re: [PATCH] fix qemu build with xen-4.18.0, Peter Maydell, 2023/12/12
- Re: [PATCH] fix qemu build with xen-4.18.0, Volodymyr Babchuk, 2023/12/12
- Re: [PATCH] fix qemu build with xen-4.18.0, Stefan Hajnoczi, 2023/12/12
- Re: [PATCH] fix qemu build with xen-4.18.0, Volodymyr Babchuk, 2023/12/12
- Re: [PATCH] fix qemu build with xen-4.18.0, Stefan Hajnoczi, 2023/12/12
- Re: [PATCH] fix qemu build with xen-4.18.0, Anthony PERARD, 2023/12/12