From: Anthony PERARD <anthony.perard@citrix.com>
To: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
Cc: "Stefano Stabellini" <sstabellini@kernel.org>,
"Oleksandr Tyshchenko" <Oleksandr_Tyshchenko@epam.com>,
"Vikram Garhwal" <vikram.garhwal@amd.com>,
"Daniel P. Berrangé" <berrange@redhat.com>,
"Michael Young" <m.a.young@durham.ac.uk>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH] fix qemu build with xen-4.18.0
Date: Tue, 12 Dec 2023 16:00:29 +0000 [thread overview]
Message-ID: <9f0c39eb-f750-4f63-a033-f6edb86fbd79@perard> (raw)
In-Reply-To: <87wmtj77sl.fsf@epam.com>
On Tue, Dec 12, 2023 at 03:35:50PM +0000, Volodymyr Babchuk wrote:
> Hi Anthony
>
> Anthony PERARD <anthony.perard@citrix.com> writes:
>
> > 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").
>
> I am currently trying to upstream this patch. It is in the QEMU mailing
> list but it was never accepted. It is not reviewed in fact. I'll take a
> look at it, but I don't understand how did you get in the first place.
Sorry, I got the wrong commit pasted, I actually meant:
0c8ab1cddd6c ("xen_arm: Create virtio-mmio devices during initialization")
--
Anthony PERARD
prev parent reply other threads:[~2023-12-12 16:01 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-07 23:12 [PATCH] fix qemu build with xen-4.18.0 Michael Young
2023-12-08 8:47 ` Richard W.M. Jones
2023-12-08 9:59 ` Richard W.M. Jones
2023-12-08 10:00 ` Richard W.M. Jones
2023-12-08 9:25 ` Daniel P. Berrangé
2023-12-08 10:59 ` Peter Maydell
2023-12-08 11:34 ` Daniel P. Berrangé
2023-12-08 22:49 ` Stefano Stabellini
2023-12-12 14:19 ` Anthony PERARD
2023-12-12 14:36 ` Peter Maydell
2023-12-12 15:35 ` Volodymyr Babchuk
2023-12-12 15:47 ` Stefan Hajnoczi
2023-12-12 16:02 ` Volodymyr Babchuk
2023-12-12 16:29 ` Stefan Hajnoczi
2023-12-12 16:00 ` Anthony PERARD [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9f0c39eb-f750-4f63-a033-f6edb86fbd79@perard \
--to=anthony.perard@citrix.com \
--cc=Oleksandr_Tyshchenko@epam.com \
--cc=Volodymyr_Babchuk@epam.com \
--cc=berrange@redhat.com \
--cc=m.a.young@durham.ac.uk \
--cc=qemu-devel@nongnu.org \
--cc=sstabellini@kernel.org \
--cc=vikram.garhwal@amd.com \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).