qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Fabrice Bellard <fabrice@bellard.org>
To: l_indien@magic.fr, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Removal of some target CPU macros
Date: Wed, 07 Nov 2007 22:55:57 +0100	[thread overview]
Message-ID: <4732346D.9060304@bellard.org> (raw)
In-Reply-To: <1194463004.855.41.camel@jma4.dev.netgem.com>

Jocelyn Mayer wrote:
> On Wed, 2007-11-07 at 19:32 +0100, Fabrice Bellard wrote:
>> I noticed that some target CPUs macros have been added while they do not
>> seem necessary. I don't like that because it introduces more #ifdefs
>> which prevent making a version supporting simultaneously all the CPUs.
>>
>> In particular I saw the following:
>>
>> - TARGET_MIPSN32 : it is always combined with TARGET_MIPS64 in
>> target-mips/. If its only usage is to select a different Linux ABI, then
>> I suggest keeping TARGET_MIPS64 and using another define to choose that.
>>
>> - TARGET_PPC64H, TARGET_PPCEMB : I see no reason why they cannot be
>> handled dynamically as the other PowerPC CPU types, provided that
>> TARGET_PPC64 is defined. Is it the long term plan ?
> 
> PowerPC embedded models are already available (should say should be as
> none are actually implemented) when PPC64 is defined. But as those are
> mainly PowerPC 32 with some extensions to manipulate the 64 bits GPR,
> it's a great help if we can avoid doing all operations in 64 bits when
> running on a 32 bits host (which would greatly decrease performances by
> at least a factor of two, which is not acceptable). Then having a
> specific 32 bits target using 64 bits register is very useful if one
> want to use those features, but may be disabled if the host is 64 bits.
> Note that most (all ?) embedded Freescale PowerPC microcontrollers
> implement those extensions and that some ones are greatly interrested
> with having an usable emulation avaible for those CPUs.

OK for the speed gain, but such features make the code more difficult to
test because there are a lot of possible combinations. I'd say the same
about the fact that ppc_gpr_t can be 64 bit long on a pure 32 bit CPU.

> The PowerPC 64 with hypervisor mode support could be removed only if:
> - the fact of emulating hypervisor feature do not slowdown the emulator
> (which I greatly doubt, but there may be great surprises)

I greatly doubt too.

> - someone provide an open-source hypervisor, compatible with the ones
> used on real machines, that would allow at least Linux to be able to run
> on a CPU with hypervisor mode available. Most 64 bits PowerPC, including
> the 970 (ie G5) have the hypervisor mode support implemented. If the
> hypervisor mode emulation is present, the OS won't be allowed to access
> most SPR and some exceptions will need to have some specific handlers in
> the hypervisor firmware. As I don't know such a software available, the
> hypervisor mode can not be enabled for "standard" PowerPC 64 emulation;
> or no-one will be able to actually use the emulator, except if using the
> venerable but mostly undocumented (and nearly impossible to find on real
> hardware) PowerPC 620 CPU.
> Furthermore, running (or emulating) a SMP machine on a 64 bits PowerPC
> with hypervisor features without hypervisor software is exactly
> impossible.
> Then I don't see how we can do without a separated target for hypervisor
> features support.

What you say does not justify the separate ppc64h target : it just
implies that you need to add a separate machine to make hypervisor tests.

Fabrice.

  reply	other threads:[~2007-11-07 21:57 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-07 18:32 [Qemu-devel] Removal of some target CPU macros Fabrice Bellard
2007-11-07 19:16 ` Jocelyn Mayer
2007-11-07 21:55   ` Fabrice Bellard [this message]
2007-11-07 22:28     ` J. Mayer
2007-11-07 22:55       ` Fabrice Bellard
2007-11-07 23:12         ` Bernhard Fischer
2007-11-07 23:36           ` Paul Brook
     [not found]       ` <200711072247.53354.paul@codesourcery.com>
2007-11-07 23:06         ` J. Mayer
2007-11-07 23:37           ` Paul Brook
2007-11-09 22:04             ` J. Mayer
2007-11-08 13:09   ` Tristan Gingold
2007-11-08 20:09     ` J. Mayer
2007-11-07 22:40 ` Thiemo Seufer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4732346D.9060304@bellard.org \
    --to=fabrice@bellard.org \
    --cc=l_indien@magic.fr \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).