[Qemu-devel] [Bug 1032828] Re: 64-bit capable PPC models should be supported in 32-bit usermode.

[Samuel Bronson]

** Description changed:

  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]:
- <fxr.watson.org/fxr/source/osfmk/ppc/commpage/bzero_128.s?v=xnu-1228>
+ <http://fxr.watson.org/fxr/source/osfmk/ppc/commpage/bzero_128.s?v=xnu-1228>

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1032828

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

Status in QEMU:
  New

Bug description:
  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>

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1032828/+subscriptions