Re: [Xen-devel] Project idea: make QEMU more flexible

[Paolo Bonzini <pbonzini@xxxxxxxxxx>]

Il 07/01/2014 14:26, Stefano Stabellini ha scritto:
> > The identifiers poisoned by include/qemu/poison.h are
> > an initial but not complete list. Host and target
> > endianness is a particularly obvious one, as is the
> > size of a target long. You may not use these things
> > in your Xen devices, but "qemu-system-null" implies
> > more than "weird special purpose thing which only
> > has Xen devices in it".
> 
> I see your point.
> Could we allow target endinness and long size being selected at
> configure time for target-null?
> The default could be the same as the host, or could even be simply
> statically determined, maybe little endian, 4 bytes.

For Xen both long sizes are already supported by the block backend.  Are
there still guests that use BLKIF_PROTOCOL_NATIVE?  If not, long size
might not matter at all.

And if in the future Xen were to grow support for a big-endian target,
you could either enforce little-endian for the ring buffers, or
negotiate it in xenstore like you do for sizeof(long).

So let's call things by their name and add qemu-system-xenpv that covers
both x86 and ARM and anything else in the future.  Phasing out the
i386/x86_64 xenpv machine type makes total sense if the exact same code
can support ARM PV domains too.  This machine would only be compiled if
you had support for Xen.  My current patches have:

supported_target() {
    test "$tcg" = "yes" && return 0
    supported_kvm_target && return 0
    supported_xen_target && return 0
    return 1
}

but adding a more refined test for supported-on-TCG would be easy.

Paolo

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel