All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.