[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] linux-user: drop support for "unknown" host CPUs (ie hp
Re: [Qemu-devel] linux-user: drop support for "unknown" host CPUs (ie hppa and m68k) ?
Mon, 13 Jun 2016 11:40:35 +0200
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0
Le 13/06/2016 à 11:26, Peter Maydell a écrit :
> Currently our configure script allows linux-user targets to be built
> for "unknown" host CPU architectures (which must be using the TCI
> interpreter). However, code like user-exec.c has host-architecture
> #ifdef ladders which in practice mean you can't build linux-user for
> an arbitrary host architecture. The only two host architectures which
> have code in user-exec.c but aren't recognised by configure are
> HPPA and m68k.
> I'd like to move to an "every supported host architecture has a
> linux-user/host/$(ARCH)/hostdep.h header" model (this fixes a problem
> in the code currently in master where make doesn't notice it needs to
> rebuild if a host arch moves from "using generic/" to "using $(ARCH)").
> Host architectures which we sort-of-but-don't support are an annoying
> corner case I'd like to be able to drop entirely, by either:
> (1) just dropping the support outright
> (2) promoting them to at least being recognised by configure as
> a known architecture, even if one without a tcg backend
> Does this seem like a good idea?
> I think HPPA should definitely be in category (1) -- we dropped
> the TCG backend years back, and I don't think any of us has a
> machine to test changes on,.
I have an HPPA server sleeping in my garage, if someone needs it...
> Which category should m68k host support go into? Does anybody
> actually use m68k host + TCI interpreter linux-user ? My guess
> is this isn't actually used, because the m68k-specific code in
> user-exec.c doesn't set the "is_write" flag correctly, which means
> that guests which do self-modifying code won't work (including
> anything using a signal handler with an on-stack trampoline).
> So my preference would be to drop the m68k-host code too.
I've never tried to use an m68k computer as a QEMU host, and I think it
should be horribly slow (for 68040 at 40 Mhz, and I don't have coldfire).
IMHO, I see no problem to remove m68k-host (1) while it does not break
qemu-m68k and qemu-system-m68k.