ppc64-softmmu is a superset of ppc-softmmu which in turn is a superset
of ppcemb-softmmu. But since the config files are currently independent
from each other, we missed to define some CONFIG switches in the super-
sets: CONFIG_SUNGEM is missing from the ppc64-softmmu config, and the
CONFIG_IDE_SII3112 switch is only defined in ppcemb-softmmu.
Let's fix this by including the subsets instead of duplicating all the
switches all over the place.
(off-topic question: Do we still need a separate ppcemb-softmmu nowadays?
It seemed to be useful 10 years ago when everybody was doing KVM on
embedded PPC, but these days seem to be pretty much over now, so IMHO
just using ppc-softmmu for embedded should be enough nowadays? We could
save quite some compilation- and "make check"-time if we could finally get
rid of ppcemb-softmmu again...)
Thomas Huth (2):
default-configs/ppc64-softmmu: Include 32-bit configs instead of
copying them
default-configs/ppc-softmmu: Restructure the switches according to the
machines
default-configs/ppc-softmmu.mak | 59 +++++++++++++++----------------------
default-configs/ppc64-softmmu.mak | 61 +++++----------------------------------
2 files changed, 32 insertions(+), 88 deletions(-)
--
1.8.3.1
On Mon, 15 Jan 2018 10:30:53 +0100 Thomas Huth <thuth@redhat.com> wrote: > ppc64-softmmu is a superset of ppc-softmmu which in turn is a superset Hi Thomas, Per curiosity. I understand that a 64-bit ppc CPU is expected to support 32-bit ppc code, but does QEMU really need to emulate setups that likely never existed in real life (like a PowerMac G5 or a pSeries with an internal floppy disk controller for example) ? I ask because Murilo and I had a chat about removing CONFIG_FDC from default-configs/ppc64-softmmu.mak the other day :) Cheers, -- Greg > of ppcemb-softmmu. But since the config files are currently independent > from each other, we missed to define some CONFIG switches in the super- > sets: CONFIG_SUNGEM is missing from the ppc64-softmmu config, and the > CONFIG_IDE_SII3112 switch is only defined in ppcemb-softmmu. > > Let's fix this by including the subsets instead of duplicating all the > switches all over the place. > > (off-topic question: Do we still need a separate ppcemb-softmmu nowadays? > It seemed to be useful 10 years ago when everybody was doing KVM on > embedded PPC, but these days seem to be pretty much over now, so IMHO > just using ppc-softmmu for embedded should be enough nowadays? We could > save quite some compilation- and "make check"-time if we could finally get > rid of ppcemb-softmmu again...) > > Thomas Huth (2): > default-configs/ppc64-softmmu: Include 32-bit configs instead of > copying them > default-configs/ppc-softmmu: Restructure the switches according to the > machines > > default-configs/ppc-softmmu.mak | 59 +++++++++++++++---------------------- > default-configs/ppc64-softmmu.mak | 61 +++++---------------------------------- > 2 files changed, 32 insertions(+), 88 deletions(-) >
On 15.01.2018 12:05, Greg Kurz wrote: > On Mon, 15 Jan 2018 10:30:53 +0100 > Thomas Huth <thuth@redhat.com> wrote: > >> ppc64-softmmu is a superset of ppc-softmmu which in turn is a superset > > Hi Thomas, > > Per curiosity. I understand that a 64-bit ppc CPU is expected to support > 32-bit ppc code, but does QEMU really need to emulate setups that likely > never existed in real life (like a PowerMac G5 or a pSeries with an > internal floppy disk controller for example) ? I think the CONFIG_FDC switch is there for the PReP machine, not for the Macs. Thomas
On Mon, 15 Jan 2018, Thomas Huth wrote: > ppc64-softmmu is a superset of ppc-softmmu which in turn is a superset > of ppcemb-softmmu. But since the config files are currently independent > from each other, we missed to define some CONFIG switches in the super- > sets: CONFIG_SUNGEM is missing from the ppc64-softmmu config, and the > CONFIG_IDE_SII3112 switch is only defined in ppcemb-softmmu. I'm not sure about this. The Sun GEM network interface is a device typically found on Apple PowerMacs but also seems to be found on G5 based Macs so it's probably OK to add. The SiI3112 is now only used on the (not yet fully merged) Sam460EX emulation which is to be added to ppcemb, that's why I've only added it to that target. Defining it on other targets does no harm (other than making the binary bigger) just maybe not necessary. If you think this makes the configs simpler I'm OK with this change just note that it probably makes it impossible to add options only for ppcemb without also adding them to ppc and ppc64. If that's OK then go ahead. > (off-topic question: Do we still need a separate ppcemb-softmmu nowadays? > It seemed to be useful 10 years ago when everybody was doing KVM on > embedded PPC, but these days seem to be pretty much over now, so IMHO > just using ppc-softmmu for embedded should be enough nowadays? We could > save quite some compilation- and "make check"-time if we could finally get > rid of ppcemb-softmmu again...) I've also noticed that most of the boards were available both in ppcemb and ppc targets so maybe these could be merged now to avoid confusion but I don't know the reason why ppcemb existed in the first place so I don't know what other implications dropping ppcemb may have. Regards, BALATON Zoltan
On 15.01.2018 13:00, BALATON Zoltan wrote: > On Mon, 15 Jan 2018, Thomas Huth wrote: >> ppc64-softmmu is a superset of ppc-softmmu which in turn is a superset >> of ppcemb-softmmu. But since the config files are currently independent >> from each other, we missed to define some CONFIG switches in the super- >> sets: CONFIG_SUNGEM is missing from the ppc64-softmmu config, and the >> CONFIG_IDE_SII3112 switch is only defined in ppcemb-softmmu. > > I'm not sure about this. The Sun GEM network interface is a device > typically found on Apple PowerMacs but also seems to be found on G5 > based Macs so it's probably OK to add. The SiI3112 is now only used on > the (not yet fully merged) Sam460EX emulation which is to be added to > ppcemb, that's why I've only added it to that target. But as I wrote: ppc-softmmu is currently a superset of ppcemb-softmmu. I think people expect to be able to run the same amount of machines with ppc-softmmu than with ppcemb-softmmu, don't they? >> (off-topic question: Do we still need a separate ppcemb-softmmu nowadays? >> It seemed to be useful 10 years ago when everybody was doing KVM on >> embedded PPC, but these days seem to be pretty much over now, so IMHO >> just using ppc-softmmu for embedded should be enough nowadays? We could >> save quite some compilation- and "make check"-time if we could finally >> get rid of ppcemb-softmmu again...) > > I've also noticed that most of the boards were available both in ppcemb > and ppc targets so maybe these could be merged now to avoid confusion > but I don't know the reason why ppcemb existed in the first place so I > don't know what other implications dropping ppcemb may have. An alternative would be to remove the embedded configs from the ppc-softmmu.mak and only include them in ppcemb-softmmu.mak, so that there is a stricter distinction. I think the current situation is rather confusing, where it is possible that the user could try to run a pseries machine with an embedded PPC CPU for example ... so strictly separating the embedded stuff into ppcemb-softmmu would maybe really make sense. Thomas
On 15.01.2018 13:00, BALATON Zoltan wrote: [...] > I've also noticed that most of the boards were available both in ppcemb > and ppc targets so maybe these could be merged now to avoid confusion > but I don't know the reason why ppcemb existed in the first place so I > don't know what other implications dropping ppcemb may have. FYI: I've had a chat with Alexander Graf this morning in IRC, and the qemu-system-ppcemb was indeed only created for supporting the CPUs with page sizes < 4k. Everything else is supposed to work with qemu-system-ppc, too. Since likely nobody is using page sizes < 4k on embedded PPCs nowadays anymore (and Alex was also only aware of one home-brew OS that did this in the past is likely not available now anymore), I think we can go forward and start the deprecation of ppcemb. Thomas
On 16 January 2018 at 10:41, Thomas Huth <thuth@redhat.com> wrote: > On 15.01.2018 13:00, BALATON Zoltan wrote: > [...] >> I've also noticed that most of the boards were available both in ppcemb >> and ppc targets so maybe these could be merged now to avoid confusion >> but I don't know the reason why ppcemb existed in the first place so I >> don't know what other implications dropping ppcemb may have. > > FYI: I've had a chat with Alexander Graf this morning in IRC, and the > qemu-system-ppcemb was indeed only created for supporting the CPUs with > page sizes < 4k. Everything else is supposed to work with > qemu-system-ppc, too. Since likely nobody is using page sizes < 4k on > embedded PPCs nowadays anymore (and Alex was also only aware of one > home-brew OS that did this in the past is likely not available now > anymore), I think we can go forward and start the deprecation of ppcemb. We do now support runtime-settable page sizes (as a board model property), so you could roll support for 1K pages into ppc-softmmu/ppc64-softmmu if you wanted. thanks -- PMM
On 16.01.2018 11:51, Peter Maydell wrote: > On 16 January 2018 at 10:41, Thomas Huth <thuth@redhat.com> wrote: >> On 15.01.2018 13:00, BALATON Zoltan wrote: >> [...] >>> I've also noticed that most of the boards were available both in ppcemb >>> and ppc targets so maybe these could be merged now to avoid confusion >>> but I don't know the reason why ppcemb existed in the first place so I >>> don't know what other implications dropping ppcemb may have. >> >> FYI: I've had a chat with Alexander Graf this morning in IRC, and the >> qemu-system-ppcemb was indeed only created for supporting the CPUs with >> page sizes < 4k. Everything else is supposed to work with >> qemu-system-ppc, too. Since likely nobody is using page sizes < 4k on >> embedded PPCs nowadays anymore (and Alex was also only aware of one >> home-brew OS that did this in the past is likely not available now >> anymore), I think we can go forward and start the deprecation of ppcemb. > > We do now support runtime-settable page sizes (as a board model property), > so you could roll support for 1K pages into ppc-softmmu/ppc64-softmmu > if you wanted. Yes, I've noticed this TARGET_PAGE_BITS_VARY stuff in target/arm/ already ... I think that's a good plan B if someone speaks up claiming that <4k page sizes are still required after we've marked ppcemb as deprecated. Thomas
On 15 January 2018 at 09:30, Thomas Huth <thuth@redhat.com> wrote: > (off-topic question: Do we still need a separate ppcemb-softmmu nowadays? > It seemed to be useful 10 years ago when everybody was doing KVM on > embedded PPC, but these days seem to be pretty much over now, so IMHO > just using ppc-softmmu for embedded should be enough nowadays? We could > save quite some compilation- and "make check"-time if we could finally get > rid of ppcemb-softmmu again...) There are some specific differences guarded by TARGET_PPCEMB, like the way it has a different TARGET_PAGE_BITS value, and some code in target/ppc/kvm.c related to telling KVM about interrupts. You would need to make those all be runtime decisions I assume. thanks -- PMM
On 15.01.2018 14:01, Peter Maydell wrote: > On 15 January 2018 at 09:30, Thomas Huth <thuth@redhat.com> wrote: >> (off-topic question: Do we still need a separate ppcemb-softmmu nowadays? >> It seemed to be useful 10 years ago when everybody was doing KVM on >> embedded PPC, but these days seem to be pretty much over now, so IMHO >> just using ppc-softmmu for embedded should be enough nowadays? We could >> save quite some compilation- and "make check"-time if we could finally get >> rid of ppcemb-softmmu again...) > > There are some specific differences guarded by TARGET_PPCEMB, like > the way it has a different TARGET_PAGE_BITS value, and some code > in target/ppc/kvm.c related to telling KVM about interrupts. You > would need to make those all be runtime decisions I assume. True ... but while we maybe could turn those into runtime checks, I now rather think it's maybe better to go the other way round: Maybe we should not include each and everything into ppc64-softmmu, but put the embedded stuff only in ppcemb-softmmu and the 32-bit stuff only in ppc-softmmu instead? That way we could, for example, also make the output of "-cpu help" and "-device help" a little bit more user friendly... Thomas
On Mon, Jan 15, 2018 at 03:42:09PM +0100, Thomas Huth wrote: > On 15.01.2018 14:01, Peter Maydell wrote: > > On 15 January 2018 at 09:30, Thomas Huth <thuth@redhat.com> wrote: > >> (off-topic question: Do we still need a separate ppcemb-softmmu nowadays? > >> It seemed to be useful 10 years ago when everybody was doing KVM on > >> embedded PPC, but these days seem to be pretty much over now, so IMHO > >> just using ppc-softmmu for embedded should be enough nowadays? We could > >> save quite some compilation- and "make check"-time if we could finally get > >> rid of ppcemb-softmmu again...) > > > > There are some specific differences guarded by TARGET_PPCEMB, like > > the way it has a different TARGET_PAGE_BITS value, and some code > > in target/ppc/kvm.c related to telling KVM about interrupts. You > > would need to make those all be runtime decisions I assume. > > True ... but while we maybe could turn those into runtime checks, I now > rather think it's maybe better to go the other way round: Maybe we > should not include each and everything into ppc64-softmmu, but put the > embedded stuff only in ppcemb-softmmu and the 32-bit stuff only in > ppc-softmmu instead? That way we could, for example, also make the > output of "-cpu help" and "-device help" a little bit more user friendly... I tend to agree. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
© 2016 - 2024 Red Hat, Inc.