[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH] fix qemu build with xen-4.18.0
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |