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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Tue, 7 Jan 2014, Paolo Bonzini wrote:
> 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.

I agree with you, I would be happy with this solution.



> 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.


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