qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Removal of some target CPU macros


From: Fabrice Bellard
Subject: Re: [Qemu-devel] Removal of some target CPU macros
Date: Wed, 07 Nov 2007 22:55:57 +0100
User-agent: Thunderbird 1.5.0.9 (X11/20070212)

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 via email to

[Prev in Thread] Current Thread [Next in Thread]