Re: [Qemu-devel] [PULL 22/42] configure: factor out list of supported Xen/KVM/HAX targets

[Stefano Stabellini]

On Mon, 10 Jul 2017, Peter Maydell wrote:
> On 10 July 2017 at 17:14, Paolo Bonzini <address@hidden> wrote:
> > On 10/07/2017 17:49, Peter Maydell wrote:
> >> On 5 July 2017 at 08:14, Paolo Bonzini <address@hidden> wrote:
> >>> This will be useful when the functions are called, early in the configure
> >>> process, to filter out targets that do not support hardware acceleration.
> >>>
> >>> Signed-off-by: Paolo Bonzini <address@hidden>
> >>
> >>> +supported_xen_target() {
> >>> +    test "$xen" = "yes" || return 1
> >>> +    glob "$1" "*-softmmu" || return 1
> >>> +    case "${1%-softmmu}:$cpu" in
> >>> +        arm:arm | aarch64:aarch64 | \
> >>> +        i386:i386 | i386:x86_64 | x86_64:i386 | x86_64:x86_64)
> >>> +            return 0
> >>> +        ;;
> >>
> >> This says that arm-on-arm and aarch64-on-aarch64 are supported
> >> Xen targets...
> >
> > Hmm, this comes from my old patches.  IIRC the reason for the change,
> > when it wasn't a change (many conflicts ago) was that Xen folks were
> > using --disable-tcg because their device model for Xen PV on ARM was
> > actually an x86_64 QEMU.
> >
> > Stefano and Anthony, is this still true?  If so, would it make sense to
> > add the Xen PV machine type to qemu-system-arm---that is, is it
> > something you can whip up easily, or should I just remove that line?
> 
> I think you should just fix configure for the moment, because
> this patch wasn't supposed to change anything about what we
> build (AIUI). We can think about changing the Xen PV on ARM
> build setup as a separate thing if we want to, I suspect it
> is more invasive than a couple of lines changing in configure.

Let's leave the current build issue aside for a moment, given that it
seems to be solved now.

Today, we build qemu-system-i386 for Xen on ARM just for the xenpv
machine. Using qemu-system-i386 causes all sort of confusion in our
users and even distro packagers. Using qemu-system-aarch64 on ARM64
would be better. But the best solution I think it would be to build a
cpu-less arch-neutral xenpv machine. Something like qemu-system-null or
qemu-system-xen.