| Message ID | 1368764711-13763-1-git-send-email-david@gibson.dropbear.id.au |
|---|---|
| State | New |
| Headers | show |
On Fri, 2013-05-17 at 14:25 +1000, David Gibson wrote: > Because the pseries machine type is optional (it is only built when libfdt > is available), this can result in a build with no default machine. In that > case vl.c will print a "No machine found" message. This seems reasonable, > given that as mentioned, mac99 is unlikely to be a good choice. What happened to the idea of having libfdt source in qemu ? That's a pretty common things with libfdt... Cheers, Ben.
On Fri, May 17, 2013 at 02:36:26PM +1000, Benjamin Herrenschmidt wrote: > On Fri, 2013-05-17 at 14:25 +1000, David Gibson wrote: > > Because the pseries machine type is optional (it is only built when libfdt > > is available), this can result in a build with no default machine. In that > > case vl.c will print a "No machine found" message. This seems reasonable, > > given that as mentioned, mac99 is unlikely to be a good choice. > > What happened to the idea of having libfdt source in qemu ? That's a pretty > common things with libfdt... Still floating out there. There was talk of making it a git submodule, but it hasn't happened yet.
On 17 May 2013 06:17, David Gibson <dwg@au1.ibm.com> wrote: > On Fri, May 17, 2013 at 02:36:26PM +1000, Benjamin Herrenschmidt wrote: >> On Fri, 2013-05-17 at 14:25 +1000, David Gibson wrote: >> > Because the pseries machine type is optional (it is only built when libfdt >> > is available), this can result in a build with no default machine. In that >> > case vl.c will print a "No machine found" message. This seems reasonable, >> > given that as mentioned, mac99 is unlikely to be a good choice. >> >> What happened to the idea of having libfdt source in qemu ? That's a pretty >> common things with libfdt... > > Still floating out there. There was talk of making it a git > submodule, but it hasn't happened yet. No, the patches to make it a git submodule have gone in. If you configure with --enable-fdt and you don't have a system fdt then it should now prompt you how to pull in the submodule. I'm planning to force --enable-fdt somehow for ARM targets in 1.6; only reason I didn't for 1.5 is that the libfdt code went in fairly late in the release cycle and I figured I'd let it bed in first. If you're going to make the ppc64 default machine an fdt one you should probably force fdt for ppc too. (I'd suggest we forced it on for everything but the x86 folks would probably complain :-)) thanks -- PMM
Am 17.05.2013 um 10:47 schrieb David Gibson <dwg@au1.ibm.com>: > On Fri, May 17, 2013 at 02:36:26PM +1000, Benjamin Herrenschmidt wrote: >> On Fri, 2013-05-17 at 14:25 +1000, David Gibson wrote: >>> Because the pseries machine type is optional (it is only built when libfdt >>> is available), this can result in a build with no default machine. In that >>> case vl.c will print a "No machine found" message. This seems reasonable, >>> given that as mentioned, mac99 is unlikely to be a good choice. >> >> What happened to the idea of having libfdt source in qemu ? That's a pretty >> common things with libfdt... > > Still floating out there. There was talk of making it a git > submodule, but it hasn't happened yet. Nack w/o libfdt in the tree, ack with it in the tree :). Alex > > -- > 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
Am 17.05.2013 06:25, schrieb David Gibson: > Currently, for qemu-system-ppc64, the default machine type is 'mac99'. > Since the mac99 machine is not being actively maintained, and shows quite > a few signs of bitrot, Please be more specific than making such general claims in a commit message! As the default machine it certainly compiles, so where are you seeing bitrot? The DEC bridge cleanup that I once started kind of depends on the PCI cleanup you recently looked into. Andreas > this is not very sensible. This patch changes the > default machine to 'pseries', which is actively maintained and works well > with most modern ppc64 Linux distributions as a guest. > > Because the pseries machine type is optional (it is only built when libfdt > is available), this can result in a build with no default machine. In that > case vl.c will print a "No machine found" message. This seems reasonable, > given that as mentioned, mac99 is unlikely to be a good choice. > > Signed-off-by: David Gibson <david@gibson.dropbear.id.au> > --- > hw/ppc/mac_newworld.c | 3 --- > hw/ppc/spapr.c | 1 + > 2 files changed, 1 insertion(+), 3 deletions(-) > > diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c > index ce44e95..dafe7d2 100644 > --- a/hw/ppc/mac_newworld.c > +++ b/hw/ppc/mac_newworld.c > @@ -458,9 +458,6 @@ static QEMUMachine core99_machine = { > .desc = "Mac99 based PowerMAC", > .init = ppc_core99_init, > .max_cpus = MAX_CPUS, > -#ifdef TARGET_PPC64 > - .is_default = 1, > -#endif > DEFAULT_MACHINE_OPTIONS, > }; > > diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c > index 74a9306..ced1b63 100644 > --- a/hw/ppc/spapr.c > +++ b/hw/ppc/spapr.c > @@ -1348,6 +1348,7 @@ static void ppc_spapr_init(QEMUMachineInitArgs *args) > static QEMUMachine spapr_machine = { > .name = "pseries", > .desc = "pSeries Logical Partition (PAPR compliant)", > + .is_default = 1, > .init = ppc_spapr_init, > .reset = ppc_spapr_reset, > .block_default_type = IF_SCSI, >
On Fri, 2013-05-17 at 09:42 +0200, Andreas Färber wrote: > Am 17.05.2013 06:25, schrieb David Gibson: > > Currently, for qemu-system-ppc64, the default machine type is 'mac99'. > > Since the mac99 machine is not being actively maintained, and shows quite > > a few signs of bitrot, > > Please be more specific than making such general claims in a commit > message! As the default machine it certainly compiles, so where are you > seeing bitrot? The DEC bridge cleanup that I once started kind of > depends on the PCI cleanup you recently looked into. It certainly doesn't actually work properly and it emulates something that doesn't exist (ie. a G5 with Cuda for god sake :-) pseries is much more useful and well maintained. Cheers, Ben. > Andreas > > > this is not very sensible. This patch changes the > > default machine to 'pseries', which is actively maintained and works well > > with most modern ppc64 Linux distributions as a guest. > > > > Because the pseries machine type is optional (it is only built when libfdt > > is available), this can result in a build with no default machine. In that > > case vl.c will print a "No machine found" message. This seems reasonable, > > given that as mentioned, mac99 is unlikely to be a good choice. > > > > Signed-off-by: David Gibson <david@gibson.dropbear.id.au> > > --- > > hw/ppc/mac_newworld.c | 3 --- > > hw/ppc/spapr.c | 1 + > > 2 files changed, 1 insertion(+), 3 deletions(-) > > > > diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c > > index ce44e95..dafe7d2 100644 > > --- a/hw/ppc/mac_newworld.c > > +++ b/hw/ppc/mac_newworld.c > > @@ -458,9 +458,6 @@ static QEMUMachine core99_machine = { > > .desc = "Mac99 based PowerMAC", > > .init = ppc_core99_init, > > .max_cpus = MAX_CPUS, > > -#ifdef TARGET_PPC64 > > - .is_default = 1, > > -#endif > > DEFAULT_MACHINE_OPTIONS, > > }; > > > > diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c > > index 74a9306..ced1b63 100644 > > --- a/hw/ppc/spapr.c > > +++ b/hw/ppc/spapr.c > > @@ -1348,6 +1348,7 @@ static void ppc_spapr_init(QEMUMachineInitArgs *args) > > static QEMUMachine spapr_machine = { > > .name = "pseries", > > .desc = "pSeries Logical Partition (PAPR compliant)", > > + .is_default = 1, > > .init = ppc_spapr_init, > > .reset = ppc_spapr_reset, > > .block_default_type = IF_SCSI, > > > >
On 17.05.2013, at 09:42, Andreas Färber wrote: > Am 17.05.2013 06:25, schrieb David Gibson: >> Currently, for qemu-system-ppc64, the default machine type is 'mac99'. >> Since the mac99 machine is not being actively maintained, and shows quite >> a few signs of bitrot, > > Please be more specific than making such general claims in a commit > message! As the default machine it certainly compiles, so where are you > seeing bitrot? The DEC bridge cleanup that I once started kind of > depends on the PCI cleanup you recently looked into. The mac99 machine for 64bit is actually worse than anything bitrot could give you. It emulates a machine that in its form never possibly could have existed in real hardware, which makes it very fragile and dependent on the guest's mercy to handle this gracefully. Given the current state and amount of development on the pseries target, I think it makes sense to declare that as the default for qemu-system-ppc64. I would still love to see -M mac99 emulate a proper U2 or U1 based system for 32bit. And I would also love to see a real U4 based emulation model come up for qemu-system-ppc64. But I doubt I'll have time to work on either :). Alex
Alexander Graf <agraf@suse.de> writes: > On 17.05.2013, at 09:42, Andreas Färber wrote: > >> Am 17.05.2013 06:25, schrieb David Gibson: >>> Currently, for qemu-system-ppc64, the default machine type is 'mac99'. >>> Since the mac99 machine is not being actively maintained, and shows quite >>> a few signs of bitrot, >> >> Please be more specific than making such general claims in a commit >> message! As the default machine it certainly compiles, so where are you >> seeing bitrot? The DEC bridge cleanup that I once started kind of >> depends on the PCI cleanup you recently looked into. > > The mac99 machine for 64bit is actually worse than anything bitrot > could give you. It emulates a machine that in its form never possibly > could have existed in real hardware, which makes it very fragile and > dependent on the guest's mercy to handle this gracefully. I'll note that we have a CONFIG_PSERIES today. I'd suggest getting rid of it first before making pseries the default. I still think spapr would be a better name than pseries FWIW since that's what it's referred to in the code. Regards, Anthony Liguori > > Given the current state and amount of development on the pseries target, I think it makes sense to declare that as the default for qemu-system-ppc64. > > I would still love to see -M mac99 emulate a proper U2 or U1 based system for 32bit. And I would also love to see a real U4 based emulation model come up for qemu-system-ppc64. But I doubt I'll have time to work on either :). > > > Alex
On 06/13/2013 01:31:48 PM, Anthony Liguori wrote: > Alexander Graf <agraf@suse.de> writes: > > > On 17.05.2013, at 09:42, Andreas Färber wrote: > > > >> Am 17.05.2013 06:25, schrieb David Gibson: > >>> Currently, for qemu-system-ppc64, the default machine type is > 'mac99'. > >>> Since the mac99 machine is not being actively maintained, and > shows quite > >>> a few signs of bitrot, > >> > >> Please be more specific than making such general claims in a commit > >> message! As the default machine it certainly compiles, so where > are you > >> seeing bitrot? The DEC bridge cleanup that I once started kind of > >> depends on the PCI cleanup you recently looked into. > > > > The mac99 machine for 64bit is actually worse than anything bitrot > > could give you. It emulates a machine that in its form never > possibly > > could have existed in real hardware, which makes it very fragile and > > dependent on the guest's mercy to handle this gracefully. > > I'll note that we have a CONFIG_PSERIES today. I'd suggest getting > rid > of it first before making pseries the default. Why? As long as it's present in the default ppc64 build, you'll have a default machine. If a user makes a custom config without it, presumably they know they want to run some other machine, so why do you need a default? QEMU has too much mandatory stuff as is. -Scott
Scott Wood <scottwood@freescale.com> writes: > On 06/13/2013 01:31:48 PM, Anthony Liguori wrote: >> Alexander Graf <agraf@suse.de> writes: >> >> > On 17.05.2013, at 09:42, Andreas Färber wrote: >> > >> >> Am 17.05.2013 06:25, schrieb David Gibson: >> >>> Currently, for qemu-system-ppc64, the default machine type is >> 'mac99'. >> >>> Since the mac99 machine is not being actively maintained, and >> shows quite >> >>> a few signs of bitrot, >> >> >> >> Please be more specific than making such general claims in a commit >> >> message! As the default machine it certainly compiles, so where >> are you >> >> seeing bitrot? The DEC bridge cleanup that I once started kind of >> >> depends on the PCI cleanup you recently looked into. >> > >> > The mac99 machine for 64bit is actually worse than anything bitrot >> > could give you. It emulates a machine that in its form never >> possibly >> > could have existed in real hardware, which makes it very fragile and >> > dependent on the guest's mercy to handle this gracefully. >> >> I'll note that we have a CONFIG_PSERIES today. I'd suggest getting >> rid >> of it first before making pseries the default. > > Why? I believe it's there only because libfdt used to be optional. libfdt is no longer optional. > As long as it's present in the default ppc64 build, you'll have a > default machine. If a user makes a custom config without it, > presumably they know they want to run some other machine, so why do you > need a default? That's fair. Regards, Anthony Liguori > > QEMU has too much mandatory stuff as is. > > -Scott
On 13 June 2013 20:02, Anthony Liguori <aliguori@us.ibm.com> wrote: > I believe it's there only because libfdt used to be optional. libfdt is > no longer optional. Technically speaking those patches haven't actually been committed yet ;-) [partly because it needs a trivial fixup and I haven't either resent with the fix or stuffed it into arm-devs or some other tree, so my fault really.] I was actually putting together a bunch of configury patches into a branch for possible submission as a pullreq today, including that one, but some of the stuff in that pullreq would clash with the aarch64 tcg pullreq currently on the list, so I'd prefer to wait for that to be committed first. thanks -- PMM
Am 13.06.2013 15:49, schrieb Alexander Graf: > On 17.05.2013, at 09:42, Andreas Färber wrote: >> Am 17.05.2013 06:25, schrieb David Gibson: >>> Currently, for qemu-system-ppc64, the default machine type is 'mac99'. >>> Since the mac99 machine is not being actively maintained, and shows quite >>> a few signs of bitrot, >> >> Please be more specific than making such general claims in a commit >> message! As the default machine it certainly compiles, so where are you >> seeing bitrot? The DEC bridge cleanup that I once started kind of >> depends on the PCI cleanup you recently looked into. > > The mac99 machine for 64bit is actually worse than anything bitrot could give you. It emulates a machine that in its form never possibly could have existed in real hardware, which makes it very fragile and dependent on the guest's mercy to handle this gracefully. Still we should put that in the commit message and not "shows quite a few signs of bitrot". Bitrot is what gus.c and cs4231a.c may have endured while not being compiled in or those disabled DPRINTF()s sprinkled all over the code base. Further, David is looking at this from a biased perspective: -M pseries is best maintained (apart from e500) ppc target, but it doesn't work with PR KVM (not on my box anyway). But neither does mac99 on KVM due to page sizes or something IIRC. However under TCG either is okay with the guests I've seen so far and they all compile warning-free. pseries used to hang, that is no longer the case, it just doesn't do anything now - still need to debug how to improve that. > Given the current state and amount of development on the pseries target, I think it makes sense to declare that as the default for qemu-system-ppc64. No disagreement there then. Andreas > I would still love to see -M mac99 emulate a proper U2 or U1 based system for 32bit. And I would also love to see a real U4 based emulation model come up for qemu-system-ppc64. But I doubt I'll have time to work on either :). > > > Alex
Am 13.06.2013 21:02, schrieb Anthony Liguori: > Scott Wood <scottwood@freescale.com> writes: > >> On 06/13/2013 01:31:48 PM, Anthony Liguori wrote: >>> I'll note that we have a CONFIG_PSERIES today. I'd suggest getting >>> rid >>> of it first before making pseries the default. >> >> Why? > > I believe it's there only because libfdt used to be optional. Isn't that define rather related to pseries being ppc64-only? Andreas
On Fri, 2013-06-14 at 16:28 +0200, Andreas Färber wrote: > > I would still love to see -M mac99 emulate a proper U2 or U1 based > system for 32bit. And I would also love to see a real U4 based > emulation model come up for qemu-system-ppc64. But I doubt I'll have > time to work on either :). Uninorth itself is easy, the guests don't mess with it much, and we have the infrastructure for iommu's nowadays. KL is the interesting bit. The main missing piece of the puzzle is really a PMU device. There are other bits in the chipset like GEM ethernet and the Frodo SATA but: - They are probed using PCI probing, so not having them isn't a huge deal. - A GEM emulation shouldn't be terribly hard, there's bunch of registers manipulated by the driver that we can probably just ignore. - A Frodo emulation would be trivial considered that the driver doesn't use anything but basic MMIO taskfile access (so does the MacOS driver) and a bit of SCRs. Now if only I had more spare time ... :-) Cheers, Ben.
On Fri, Jun 14, 2013 at 04:28:32PM +0200, Andreas Färber wrote: > Am 13.06.2013 15:49, schrieb Alexander Graf: > > On 17.05.2013, at 09:42, Andreas Färber wrote: > >> Am 17.05.2013 06:25, schrieb David Gibson: > >>> Currently, for qemu-system-ppc64, the default machine type is 'mac99'. > >>> Since the mac99 machine is not being actively maintained, and shows quite > >>> a few signs of bitrot, > >> > >> Please be more specific than making such general claims in a commit > >> message! As the default machine it certainly compiles, so where are you > >> seeing bitrot? The DEC bridge cleanup that I once started kind of > >> depends on the PCI cleanup you recently looked into. > > > > The mac99 machine for 64bit is actually worse than anything bitrot could give you. It emulates a machine that in its form never possibly could have existed in real hardware, which makes it very fragile and dependent on the guest's mercy to handle this gracefully. > > Still we should put that in the commit message and not "shows quite a > few signs of bitrot". Bitrot is what gus.c and cs4231a.c may have > endured while not being compiled in or those disabled DPRINTF()s > sprinkled all over the code base. > > Further, David is looking at this from a biased perspective: -M pseries > is best maintained (apart from e500) ppc target, but it doesn't work > with PR KVM (not on my box anyway). But neither does mac99 on KVM due to > page sizes or something IIRC. However under TCG either is okay with the > guests I've seen so far and they all compile warning-free. > > pseries used to hang, that is no longer the case, it just doesn't do > anything now - still need to debug how to improve that. > > > Given the current state and amount of development on the pseries > target, I think it makes sense to declare that as the default for > qemu-system-ppc64. > > No disagreement there then. Well, I've sent an updated version with a more accurate commit message to Alex Graf. It's also at git://github.com/dgibson/qemu.git, ppc-next branch. I do think that pseries is a better choice than mac99, but I tend to agree with Peter Maydell that the whole notion of a default machine is a bit silly. In any case, since I'm no longer actively working on qemu ppc, I don't really care enough to argue about it, so I guess it's up to Alex.
diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c index ce44e95..dafe7d2 100644 --- a/hw/ppc/mac_newworld.c +++ b/hw/ppc/mac_newworld.c @@ -458,9 +458,6 @@ static QEMUMachine core99_machine = { .desc = "Mac99 based PowerMAC", .init = ppc_core99_init, .max_cpus = MAX_CPUS, -#ifdef TARGET_PPC64 - .is_default = 1, -#endif DEFAULT_MACHINE_OPTIONS, }; diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c index 74a9306..ced1b63 100644 --- a/hw/ppc/spapr.c +++ b/hw/ppc/spapr.c @@ -1348,6 +1348,7 @@ static void ppc_spapr_init(QEMUMachineInitArgs *args) static QEMUMachine spapr_machine = { .name = "pseries", .desc = "pSeries Logical Partition (PAPR compliant)", + .is_default = 1, .init = ppc_spapr_init, .reset = ppc_spapr_reset, .block_default_type = IF_SCSI,
Currently, for qemu-system-ppc64, the default machine type is 'mac99'. Since the mac99 machine is not being actively maintained, and shows quite a few signs of bitrot, this is not very sensible. This patch changes the default machine to 'pseries', which is actively maintained and works well with most modern ppc64 Linux distributions as a guest. Because the pseries machine type is optional (it is only built when libfdt is available), this can result in a build with no default machine. In that case vl.c will print a "No machine found" message. This seems reasonable, given that as mentioned, mac99 is unlikely to be a good choice. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> --- hw/ppc/mac_newworld.c | 3 --- hw/ppc/spapr.c | 1 + 2 files changed, 1 insertion(+), 3 deletions(-)