qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 2/5] softmmu templates: optionally pass CPUState


From: Blue Swirl
Subject: Re: [Qemu-devel] [PATCH 2/5] softmmu templates: optionally pass CPUState to memory access functions
Date: Sat, 25 Aug 2012 09:18:17 +0000

On Fri, Aug 24, 2012 at 6:53 PM, Aurelien Jarno <address@hidden> wrote:
> On Fri, Aug 24, 2012 at 08:43:32PM +0200, Andreas Färber wrote:
>> Am 24.08.2012 20:05, schrieb Aurelien Jarno:
>> > On Fri, Aug 24, 2012 at 05:52:29PM +0200, Andreas Färber wrote:
>> >> Not opposed to changing the argument order, but given that we're inches
>> >> away from v1.2 (in Hard Freeze), it might be better to first get AREG0
>> >> as first argument working for your favorite hosts as a bugfix and then
>> >> do any larger optimization for v1.3.
>> >
>> > It's what I tried to do first, but I don't think it is realistic to use
>> > such a code for v1.2, it is complex to support all cases, and thus
>> > likely full of bugs. Maybe we should simply disable ARM and MIPS support
>> > for this release.
>>
>> Depends on what you mean with "disable"? Adding an #error would hurt our
>> arm build just like earlier the ppc build, and I would hope from my last
>> testing that the problems would only affect the AREG0 targets,
>> especially not ARM on ARM (or MIPS on MIPS).
>>
>
> I mean basically not building qemu-system-{alpha,i386,x86_64,or32,sparc,
> sparc64,xtensa,ppc,ppc64} on arm and mips hosts.

It should be easy to fix the call register problems by those who know
the ABIs and the fixes could be applied for stable series even after
release. Disabling the targets and enabling them later would be equal
to introducing new features which is not OK for stable branch. So I'd
just declare in release errata that there are known problem with these
less commonly used combinations and a fix may arrive later.

>
>> Aborting at runtime, only when really unsupported, would seem better.
>
> What's the point of providing non working binaries, beside getting bug
> reports?

I think the deeper problem is that most TCG targets are not actively
maintained. Does for example IA64 work at all? If we removed the
unmaintained targets, would anyone complain? Development should not be
stalled because a maintainer is absent for several months.

>
>>
>> I had taken a look at tcg/arm/ shortly after having fixed ppc (seeing
>> that there was a similar TODO or FIXME) but got distracted by other
>> projects. And your remarks wrt stack sound a bit frightening now. ;)
>> @Peter, have you looked into tcg/arm/ AREG0 support?
>>
>
>
> --
> Aurelien Jarno                          GPG: 1024D/F1BCDB73
> address@hidden                 http://www.aurel32.net



reply via email to

[Prev in Thread] Current Thread [Next in Thread]