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: Aurelien Jarno
Subject: Re: [Qemu-devel] [PATCH 2/5] softmmu templates: optionally pass CPUState to memory access functions
Date: Sat, 25 Aug 2012 14:56:00 +0200
User-agent: Mutt/1.5.20 (2009-06-14)

On Sat, Aug 25, 2012 at 09:18:17AM +0000, Blue Swirl wrote:
> 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.

The problem is that it is not that easy as said in my previous mails.
Having to support both AREG0 and non-AREG0 cases make this even worse.

My thought was to disable the support completely and add it back to 1.3
not to stable 1.2.x.

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

It is broken by recent TCG changes, but I am currently looking at that.

-- 
Aurelien Jarno                          GPG: 1024D/F1BCDB73
address@hidden                 http://www.aurel32.net



reply via email to

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