64-bit capable PPC models should be supported in 32-bit usermode.

[Samuel Bronson]

While it makes perfect sense for qemu-system-ppc not to allow the use of PPC64-capable CPU models -- it would presumably be very confusing to the poor guest operating systems -- qemu-ppc (the user-only variants) is a different story.

Sure, the most obvious PPC64 features are disabled when the processor is operating in 32-bit mode; as [PEM-64bit-3.0] says in section 1.1.1 (p. 31):

> 64-bit implementations/32-bit mode---For compatibility with
> 32-bit implementations, 64-bit implementations can be
> configured to operate in 32-bit mode by clearing the MSR[SF]
> bit. In 32-bit mode, the effective address is treated as a
> 32-bit address, condition bits, such as overflow and carry
> bits, are set based on 32-bit arithmetic (for example, integer
> overflow occurs when the result exceeds 32 bits), and the count
> register (CTR) is tested by branch conditional instructions
> following conventions for 32-bit implementations. All
> applications written for 32-bit implementations will run
> without modification on 64-bit processors running in 32-bit
> mode.

However, this does NOT make the PPC64 instructions invalid, and at least one of them is actually useful. I discovered this when my attempt to revive the darwin-user port reached the point where PPC guests would die on an "std" (store double word) instruction in the "commpage".

[ppc/cpu_capabilities.h] describes the commpage thus:

/*
 * The shared kernel/user "comm page(s)":
 *
 * The last eight pages of every address space are reserved for the kernel/user
 * "comm area". Because they can be addressed via a sign-extended 16-bit field,
 * it is particularly efficient to access code or data in the comm area with
 * absolute branches (ba, bla, bca) or absolute load/stores ("lwz r0,-4096(0)").
 * Because the comm area can be reached from anywhere, dyld is not needed.
 * Although eight pages are reserved, presently only two are populated and mapped.
 *
 * Routines on the comm page(s) can be thought of as the firmware for extended processor
 * instructions, whose opcodes are special forms of "bla". Ie, they are cpu
 * capabilities. During system initialization, the kernel populates the comm page with
 * code customized for the particular processor and platform.
 *
 * Because Mach VM cannot map the last page of an address space, the max length of
 * the comm area is seven pages.
 */

Since the darwin-user port doesn't actually support the guest_base feature (yet), and the commpage is at a fixed location on each architecture, darwin-user can't simply map a fake one when doing PPC-on-PPC or Intel-on-Intel; it therefore punts and hopes that the emulated CPU can cope with whatever code the HOST kernel has placed there based on the HOST CPU's capabilities.

In my particular case, trying to run "ppc-darwin-user/qemu-ppc /bin/ls" on a G5 (ppc970) system running Mac OS X, gdb was helpful enough to reveal that the instruction on which the guest was choking was in the __bzero() function. A bit of searching on fxr.watson.org revealed that, on this system, the kernel is using the implementation from [ppc/commpage/bzero_128.s]. Since I have no difficulty in runnning "arch -arch ppc /bin/ls", it would appear that this works fine on a G5.

I can think of four strategies for dealing with the problem:

1. Allowing PPC64-capable processors for ppc user-mode targets.

2. Somehow trapping calls into the commpage and treating them like a sort of syscall.

3. Replacing the commpage with a version that will work fine on both host and guest.

4. Cleaning up darwin-user to the point where guest_base actually works, and setting it to something like 0x2000 in this case.

[PEM-64bit-3.0]: PowerPC® Microprocessor Family: The Programming Environments Manual for 64-bit Microprocessors, Version 3.0 <https://www-01.ibm.com/chips/techlib/techlib.nsf/techdocs/F7E732FF811F783187256FDD004D3797/$file/pem_64bit_v3.0.2005jul15.pdf>

(The following sources are from xnu-1228, which is the closest fxr.watson.org has to the "xnu-1228.15.4~1" reported by "uname -v".)

[ppc/cpu_capabilities.h]: <http://fxr.watson.org/fxr/source/osfmk/ppc/cpu_capabilities.h?v=xnu-1228>

[ppc/commpage/bzero_128.s]: <http://fxr.watson.org/fxr/source/osfmk/ppc/commpage/bzero_128.s?v=xnu-1228>

[Samuel Bronson (naesten)]

Oh, by the way, I'm using Mac OS X version 10.5.8.

[Andreas Färber (afaerber)]

darwin-user has been dropped from QEMU v1.1 since no one seemed to care to make it even compile (annoying qemu-system-* users). So you don't seem to be testing a recent version, and old stable versions only get bugfixes, not new features.

For linux-user there is a separate qemu-ppc64abi32 binary for this purpose.

If you have a use case for darwin-user, feel free to reintroduce a working version by sending patches against git master:
http://wiki.qemu.org/Contribute/SubmitAPatch

[Samuel Bronson (naesten)]

On Aug 4, 2012, at 11:13 AM, Andreas Färber wrote:

> darwin-user has been dropped from QEMU v1.1 since no one seemed to
> care
> to make it even compile (annoying qemu-system-* users). So you don't
> seem to be testing a recent version, and old stable versions only get
> bugfixes, not new features

Actually, I'm attempting to resurrect darwin-user on top of master;
see <https://github.com/SamB/QEMU/commits/darwin-fixes>.

> For linux-user there is a separate qemu-ppc64abi32 binary for this
> purpose.

Ooh, now we're talking... I guess I'll copy that, then! Thanks!

> If you have a use case for darwin-user, feel free to reintroduce a
> working version by sending patches against git master:
> http://wiki.qemu.org/Contribute/SubmitAPatch

I was going to hold off on that until I got, say, /usr/bin/true
working on at least one architecture ;-).