[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [PATCH 1/8] build-system: clean up TCG/TCI configury

On 1/13/21 2:57 PM, Daniel P. Berrangé wrote:
> On Wed, Jan 13, 2021 at 02:42:51PM +0100, Helge Deller wrote:
>> On 1/13/21 2:09 PM, Philippe Mathieu-Daudé wrote:
>>> Cc'ing TCI, SH4 and PA contacts FWIW.
>>> On 1/7/21 5:06 PM, Daniel P. Berrangé wrote:
>>>> On Thu, Jan 07, 2021 at 04:50:36PM +0100, Paolo Bonzini wrote:
>>>>> On 07/01/21 16:01, Peter Maydell wrote:
>>>>>> On Thu, 7 Jan 2021 at 14:03, Paolo Bonzini <pbonzini@redhat.com> wrote:
>>>>>>> Make CONFIG_TCG_INTERPRETER a Meson option, and enable TCI (though with
>>>>>>> a warning) if the host CPU is unsupported, making it more similar to
>>>>>>> other --enable-* options.
>>>>>> The current behaviour is kind of deliberate. Using the TCG
>>>>>> interpreter is a terrible idea and think it's better if we
>>>>>> don't let users end up using it without realising that they have.
>>>>>> (Personally I would vote to deprecate-and-delete TCI, and also
>>>>>> to just have configure error out on unknown host CPU architectures.)
>>>>> Fair enough, I can change this back of course.  The missing targets are
>>>>> parisc, ia64 and sh4 I guess.
>>>> ia64 is a dead host architecture and doesn't exist in any OS distro that
>>>> we target anymore, so I don't think we need to consider it.
>> I have no opinion about ia64.
>>>> Likewise parisc/hppa doesn't seem exist in Debian since Squeeze, so I
>>>> think we can rule that out too.
>> Can we please keep parisc/hppa.
>> It's not an official platform any longer, but quite active in the
>> "unstable" debian-ports repository:
>> https://buildd.debian.org/status/architecture.php?a=hppa&suite=sid
>>>> Only sh4 still seems to be supported in Debian. I expect the primary
>>>> need there is for sh4 guest support rather than sh4 host support.
>> Same as for hppa/parisc, sh4 is in debian-ports too.
> So that at least shows that we need *guest target* support hppa/sha4.


> The question still remains whether anyone is actually likely to be
> running/using QEMU on a sh4/hppa *host*, to emulate a different
> guest arch ?

Agreed, it's not very useful because of speed and amount of possible
users, but ....(please read below)

> This is what that TCG interpreter provides for. eg would anyone
> really want to emulate aarch64 guest when runing on a hppa host ?
In debian many packages directly and indirectly depend on the qemu
source package, because it provides - beside the emulator - various
userspace tools which are necessary natively, like e.g. qemu-img.
In the past building those tools failed on hppa because the configure script
detected that neither native TCG nor TCG interpreter support was possible.
As such the configuration aborted and no tools were built.
So, the change should still make it possible to enable building the userspace

On the other side, sometimes even a slow TCG-interpreter enabled qemu
for other arches can be useful. It's not about speed, but about the
*possibility* to emulate small pieces of different code, e.g.
cross-compilers, bios-tools and such. It's not used often, but it
can be handy.
That said, if it doesn't hurt I think we should not disable something
which can be useful (this applies to all architectures).


Reply to: