[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Project idea: make QEMU more flexible
From: |
Stefano Stabellini |
Subject: |
Re: [Qemu-devel] Project idea: make QEMU more flexible |
Date: |
Tue, 7 Jan 2014 14:34:37 +0000 |
User-agent: |
Alpine 2.02 (DEB 1266 2009-07-14) |
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.
- [Qemu-devel] Project idea: make QEMU more flexible, Wei Liu, 2014/01/06
- Re: [Qemu-devel] Project idea: make QEMU more flexible, Peter Crosthwaite, 2014/01/06
- Re: [Qemu-devel] Project idea: make QEMU more flexible, Wei Liu, 2014/01/06
- Re: [Qemu-devel] Project idea: make QEMU more flexible, Peter Maydell, 2014/01/06
- Re: [Qemu-devel] Project idea: make QEMU more flexible, Stefano Stabellini, 2014/01/06
- Re: [Qemu-devel] Project idea: make QEMU more flexible, Peter Maydell, 2014/01/06
- Re: [Qemu-devel] Project idea: make QEMU more flexible, Stefano Stabellini, 2014/01/07
- Re: [Qemu-devel] Project idea: make QEMU more flexible, Peter Maydell, 2014/01/07
- Re: [Qemu-devel] Project idea: make QEMU more flexible, Paolo Bonzini, 2014/01/07
- Re: [Qemu-devel] Project idea: make QEMU more flexible,
Stefano Stabellini <=
- Re: [Qemu-devel] Project idea: make QEMU more flexible, Wei Liu, 2014/01/07
- Re: [Qemu-devel] Project idea: make QEMU more flexible, Paolo Bonzini, 2014/01/07
- Re: [Qemu-devel] Project idea: make QEMU more flexible, Peter Maydell, 2014/01/07
- Re: [Qemu-devel] Project idea: make QEMU more flexible, Paolo Bonzini, 2014/01/07
Re: [Qemu-devel] [Xen-devel] Project idea: make QEMU more flexible, Frediano Ziglio, 2014/01/06