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

[Paolo Bonzini <pbonzini@redhat.com>]

Il 07/01/2014 15:38, Wei Liu ha scritto:
> On Tue, Jan 07, 2014 at 02:50:12PM +0100, 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
> 
> I think this makes sense. But does it deserve to be in default-configs/?

Sure.  You could build a qemu-system-xenpv variant that doesn't have the
framebuffer, for example.

> It will become default-configs/xenpv-softmmu.mak and target-xenpv shall be
> created.

Yes, exactly.

> I think implementing qemu-system-xenpv will be easier after your TCG
> series goes in. In that case I don't need to worry about TCG stubs
> anymore.

Right.

Paolo