* [Qemu-devel] Removal of some target CPU macros @ 2007-11-07 18:32 Fabrice Bellard 2007-11-07 19:16 ` Jocelyn Mayer 2007-11-07 22:40 ` Thiemo Seufer 0 siblings, 2 replies; 13+ messages in thread From: Fabrice Bellard @ 2007-11-07 18:32 UTC (permalink / raw) To: qemu-devel 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 ? Regards, Fabrice. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Qemu-devel] Removal of some target CPU macros 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 2007-11-08 13:09 ` Tristan Gingold 2007-11-07 22:40 ` Thiemo Seufer 1 sibling, 2 replies; 13+ messages in thread From: Jocelyn Mayer @ 2007-11-07 19:16 UTC (permalink / raw) To: qemu-devel 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. 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) - 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. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Qemu-devel] Removal of some target CPU macros 2007-11-07 19:16 ` Jocelyn Mayer @ 2007-11-07 21:55 ` Fabrice Bellard 2007-11-07 22:28 ` J. Mayer 2007-11-08 13:09 ` Tristan Gingold 1 sibling, 1 reply; 13+ messages in thread From: Fabrice Bellard @ 2007-11-07 21:55 UTC (permalink / raw) To: l_indien, qemu-devel 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. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Qemu-devel] Removal of some target CPU macros 2007-11-07 21:55 ` Fabrice Bellard @ 2007-11-07 22:28 ` J. Mayer 2007-11-07 22:55 ` Fabrice Bellard [not found] ` <200711072247.53354.paul@codesourcery.com> 0 siblings, 2 replies; 13+ messages in thread From: J. Mayer @ 2007-11-07 22:28 UTC (permalink / raw) To: qemu-devel On Wed, 2007-11-07 at 22:55 +0100, Fabrice Bellard wrote: > 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. I got no choice here, as the 64 bits extensions of those CPUs uses the GPR for computations. And the programs are supposed not to take any care of the higher 32 bits when not using those extensions. I cannot make them 64 bits for all PowerPC targets and those CPU are not PowerPC 64 ones, so they do not match neither the PowerPC target, neither the PowerPC 64 one. [...] > > - 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. There is no documented way to disable the hypervisor feature on 64 bits PowerPC CPUs, even if the Apple SMU is said to do this before the CPU boots (but there is no known way to check if it's true). Then, it will make all PowerPC 64 emulated (but the 602) unusable as there'll be no known OSS to manage them. Removing the ppc64h target means, for me, removing any option to emulate the hypervisor feature at any time (if removed) or removing the ability to use the PowerPC 64 targets the way they are when booting on Apple G5 machines (if merged with the ppc64 target). None of those options seem acceptable to me. -- J. Mayer <l_indien@magic.fr> Never organized ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Qemu-devel] Removal of some target CPU macros 2007-11-07 22:28 ` J. Mayer @ 2007-11-07 22:55 ` Fabrice Bellard 2007-11-07 23:12 ` Bernhard Fischer [not found] ` <200711072247.53354.paul@codesourcery.com> 1 sibling, 1 reply; 13+ messages in thread From: Fabrice Bellard @ 2007-11-07 22:55 UTC (permalink / raw) To: qemu-devel J. Mayer wrote: > On Wed, 2007-11-07 at 22:55 +0100, Fabrice Bellard wrote: >> 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. > > I got no choice here, as the 64 bits extensions of those CPUs uses the > GPR for computations. And the programs are supposed not to take any care > of the higher 32 bits when not using those extensions. I cannot make > them 64 bits for all PowerPC targets and those CPU are not PowerPC 64 > ones, so they do not match neither the PowerPC target, neither the > PowerPC 64 one. You have the choice to emulate SPE extensions only in the TARGET_PPC64 case. As you said it is slower, but you avoid ifdefs. My last remark : "I'd say the same about the fact that ppc_gpr_t can be 64 bit long on a pure 32 bit CPU." was unrelated to the SPE case. You have also the choice here to always force it to 32 bit. > [...] >>> - 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. > > There is no documented way to disable the hypervisor feature on 64 bits > PowerPC CPUs, even if the Apple SMU is said to do this before the CPU > boots (but there is no known way to check if it's true). Then, it will > make all PowerPC 64 emulated (but the 602) unusable as there'll be no > known OSS to manage them. > Removing the ppc64h target means, for me, removing any option to emulate > the hypervisor feature at any time (if removed) or removing the ability > to use the PowerPC 64 targets the way they are when booting on Apple G5 > machines (if merged with the ppc64 target). None of those options seem > acceptable to me. Why not adding a new CPU type such as "PPC970 with hypervisor" and keep the current PPC970 implementation as it is without the hypervisor mode. I don't see the problem in replacing the ifdefs with a new CPU model ! You cannot reasonnably tell that it is uglier than the current code. Fabrice. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Qemu-devel] Removal of some target CPU macros 2007-11-07 22:55 ` Fabrice Bellard @ 2007-11-07 23:12 ` Bernhard Fischer 2007-11-07 23:36 ` Paul Brook 0 siblings, 1 reply; 13+ messages in thread From: Bernhard Fischer @ 2007-11-07 23:12 UTC (permalink / raw) To: qemu-devel On Wed, Nov 07, 2007 at 11:55:26PM +0100, Fabrice Bellard wrote: >Why not adding a new CPU type such as "PPC970 with hypervisor" and keep >the current PPC970 implementation as it is without the hypervisor mode. >I don't see the problem in replacing the ifdefs with a new CPU model ! >You cannot reasonnably tell that it is uglier than the current code. IMHO same for i386sx. Without an FPU there is just no FPU. Without 486-specific instructions (or i586 etc. for that matter), the machine is just constrained to the one requested by the user. The fact that usually too many non ISA-imposed features are available without explicit user choice is very, very unfortunate, IMO. As always, features are or may be nice, iff and only if you are not forced to have or use them.. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Qemu-devel] Removal of some target CPU macros 2007-11-07 23:12 ` Bernhard Fischer @ 2007-11-07 23:36 ` Paul Brook 0 siblings, 0 replies; 13+ messages in thread From: Paul Brook @ 2007-11-07 23:36 UTC (permalink / raw) To: qemu-devel On Wednesday 07 November 2007, Bernhard Fischer wrote: > On Wed, Nov 07, 2007 at 11:55:26PM +0100, Fabrice Bellard wrote: > >Why not adding a new CPU type such as "PPC970 with hypervisor" and keep > >the current PPC970 implementation as it is without the hypervisor mode. > >I don't see the problem in replacing the ifdefs with a new CPU model ! > >You cannot reasonnably tell that it is uglier than the current code. > > IMHO same for i386sx. Without an FPU there is just no FPU. Without > 486-specific instructions (or i586 etc. for that matter), the machine is > just constrained to the one requested by the user. > > The fact that usually too many non ISA-imposed features are available > without explicit user choice is very, very unfortunate, IMO. > As always, features are or may be nice, iff and only if you are not > forced to have or use them.. The i386 emulation always enables all features because noone's bothered to teach it which ones are optional. I have local ARM patches (hopefully will be merged into CVS soon) that implement 5+ different ISA variants, 3 different FPUs, a SIMD vector unit and 2 completely different exception models. All in the same binary, and all of which can be turned off if for emulating cpus that don't implement a particular feature. Paul ^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <200711072247.53354.paul@codesourcery.com>]
* Re: [Qemu-devel] Removal of some target CPU macros [not found] ` <200711072247.53354.paul@codesourcery.com> @ 2007-11-07 23:06 ` J. Mayer 2007-11-07 23:37 ` Paul Brook 0 siblings, 1 reply; 13+ messages in thread From: J. Mayer @ 2007-11-07 23:06 UTC (permalink / raw) To: Paul Brook; +Cc: qemu-devel On Wed, 2007-11-07 at 22:47 +0000, Paul Brook wrote: > > Removing the ppc64h target means, for me, removing any option to emulate > > the hypervisor feature at any time (if removed) or removing the ability > > to use the PowerPC 64 targets the way they are when booting on Apple G5 > > machines (if merged with the ppc64 target). None of those options seem > > acceptable to me. > > ICBW, but it looks like it should be fairly straightforward to replace > TARGET_PPC64H with a runtime check. The only really significant overhead I > can see is having to flush an extra set of TLBs, and I guess there are ways > round that if it is a problem. I can check the hypervisor feature is not present, for emulating PowerPC 620 on a target that would have hypervisor emulation support. But I cannot do as if the CPU do not have the feature if it's actually available. The PowerPC 64 target emulates PowerPC 64 without the hypervisor feature, which actually do not exist but looks like a G5 machine when running Linux on it. If the emulator has the hypervisor feature enabled, I need an hypervisor software to boot and manage the machine (trap the hypervisor exception, update or emulate the registers the OS is not allowed to access anymore, ...), which I don't have, then I would not be able to do any test or run any OS on this emulated target (you could argue that I do not have it to test the ppc64h target too, which is true...). There is nothing in the CPU that would allow me to make it run "as if the hypervisor mode do not exists". Then I do not have anything to check. The only possible runtime solution would be to duplicate every defined 64 bits CPU to define one model supporting hypervisor feature and another acting as this feature do not exist (the register definitions / access rights are not the same, and are defined at CPU instanciation time, adding run-time checks there would cost a lot...) and hope run-time checks won't cost too much. I don't think this solution is cleaner than having a separate target, it would bring confusion for the user imho, and it does not seem easier to test. > I can see why you want CPUs with and without hypervisor mode, I'm just not > convinced it needs a separate qemu binary. -- J. Mayer <l_indien@magic.fr> Never organized ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Qemu-devel] Removal of some target CPU macros 2007-11-07 23:06 ` J. Mayer @ 2007-11-07 23:37 ` Paul Brook 2007-11-09 22:04 ` J. Mayer 0 siblings, 1 reply; 13+ messages in thread From: Paul Brook @ 2007-11-07 23:37 UTC (permalink / raw) To: qemu-devel; +Cc: J. Mayer > I can check the hypervisor feature is not present, for emulating PowerPC > 620 on a target that would have hypervisor emulation support. But I > cannot do as if the CPU do not have the feature if it's actually > available. The PowerPC 64 target emulates PowerPC 64 without the > hypervisor feature, which actually do not exist but looks like a G5 > machine when running Linux on it. If the emulator has the hypervisor > feature enabled, I need an hypervisor software to boot and manage the > machine I agree with this much. > There is nothing in the CPU that would allow me to > make it run "as if the hypervisor mode do not exists". So add one. It obviously exists conceptually, because that's what the non-hypervisor qemu emulates. > The only possible runtime solution would be to > duplicate every defined 64 bits CPU to define one model supporting > hypervisor feature and another acting as this feature do not exist (the > register definitions / access rights are not the same, and are defined > at CPU instanciation time, adding run-time checks there would cost a > lot...) and hope run-time checks won't cost too much. As I mentioned earlier, from looking at all the occurrences of TARGET_PPC64H I'd expect the runtime overhead to be minimal, if it's measurable at all. I'm not sure what you're getting at about flags being defined at instantiation time. That's the same whether you have two binaries or one. Duplicating the CPU definitions should also be fairly trivial. You're effectively already doing it when you build the separate ppc64 and ppc64h binaries. I find it hard to believe it would be hard to do the same transformation at runtime. Paul ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Qemu-devel] Removal of some target CPU macros 2007-11-07 23:37 ` Paul Brook @ 2007-11-09 22:04 ` J. Mayer 0 siblings, 0 replies; 13+ messages in thread From: J. Mayer @ 2007-11-09 22:04 UTC (permalink / raw) To: Paul Brook; +Cc: qemu-devel On Wed, 2007-11-07 at 23:37 +0000, Paul Brook wrote: > > I can check the hypervisor feature is not present, for emulating PowerPC > > 620 on a target that would have hypervisor emulation support. But I > > cannot do as if the CPU do not have the feature if it's actually > > available. The PowerPC 64 target emulates PowerPC 64 without the > > hypervisor feature, which actually do not exist but looks like a G5 > > machine when running Linux on it. If the emulator has the hypervisor > > feature enabled, I need an hypervisor software to boot and manage the > > machine > > I agree with this much. > > > There is nothing in the CPU that would allow me to > > make it run "as if the hypervisor mode do not exists". > > So add one. It obviously exists conceptually, because that's what the > non-hypervisor qemu emulates. I admit you're right, here... Maybe just disabling the "hypervisor mode" flags and cleaverly initialise all hypervisor specific registers could make it act like the current PowerPC 64 target but this is to be checked when all hypervisor features will be emulated. > > The only possible runtime solution would be to > > duplicate every defined 64 bits CPU to define one model supporting > > hypervisor feature and another acting as this feature do not exist (the > > register definitions / access rights are not the same, and are defined > > at CPU instanciation time, adding run-time checks there would cost a > > lot...) and hope run-time checks won't cost too much. > > As I mentioned earlier, from looking at all the occurrences of TARGET_PPC64H > I'd expect the runtime overhead to be minimal, if it's measurable at all. Maybe because there are a lot of things missing for the hypervisor feature to be completelly emulated... All the MMU part, specific registers, ..., is missing. > I'm not sure what you're getting at about flags being defined at instantiation > time. That's the same whether you have two binaries or one. True. > Duplicating the CPU definitions should also be fairly trivial. You're > effectively already doing it when you build the separate ppc64 and ppc64h > binaries. I find it hard to believe it would be hard to do the same > transformation at runtime. Yes, it's trivial to duplicate the CPU definitions. I'm just afraid of the confusion it could introduce for the user seeing two definitions of the same CPU. -- J. Mayer <l_indien@magic.fr> Never organized ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Qemu-devel] Removal of some target CPU macros 2007-11-07 19:16 ` Jocelyn Mayer 2007-11-07 21:55 ` Fabrice Bellard @ 2007-11-08 13:09 ` Tristan Gingold 2007-11-08 20:09 ` J. Mayer 1 sibling, 1 reply; 13+ messages in thread From: Tristan Gingold @ 2007-11-08 13:09 UTC (permalink / raw) To: l_indien, qemu-devel Two side comments: > 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. Has anyone started to implement spe ? > - 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. Does xen/ppc satisfy your requirement ? Maybe Hollis will comment. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Qemu-devel] Removal of some target CPU macros 2007-11-08 13:09 ` Tristan Gingold @ 2007-11-08 20:09 ` J. Mayer 0 siblings, 0 replies; 13+ messages in thread From: J. Mayer @ 2007-11-08 20:09 UTC (permalink / raw) To: qemu-devel; +Cc: TristanGingold On Thu, 2007-11-08 at 14:09 +0100, Tristan Gingold wrote: > Two side comments: Hi, > > 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. > > Has anyone started to implement spe ? Large parts of the SPE extensions are implemented, most fixed-point operations (but the multiply and add family) and I think almost all floating-point operations (the flags are not properly emulated, for now). But there's a lack of a CPU model that would really use it. It could be made available very easily for a test CPU for user-mode only, as it is now. The MMU model used on Freescale cores is not implemented yet, then the full-system emulation would not be possible for now. > > - 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. > > Does xen/ppc satisfy your requirement ? > Maybe Hollis will comment. I don't know really. I guess it may do for the more urgent need which is to have a fully "transparent" hypervisor that would enable the OS to access all resources. I won't bet it could be a replacement for IBM hypervisor software as the full specifications of this software have still not be fully released (the PPAR document, which describes the whole hypervisor features is still a draft). But it's a good idea, I may take a look of what it could provide. -- J. Mayer <l_indien@magic.fr> Never organized ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Qemu-devel] Removal of some target CPU macros 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 22:40 ` Thiemo Seufer 1 sibling, 0 replies; 13+ messages in thread From: Thiemo Seufer @ 2007-11-07 22:40 UTC (permalink / raw) To: Fabrice Bellard; +Cc: qemu-devel 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. I used both in combination to avoid unintended differences in CPU behaviour. I agree it is somewhat ugly, and ABI specific defines would be better. I will make a patch when I find time for it. Thiemo ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2007-11-09 22:04 UTC | newest] Thread overview: 13+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 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 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
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).