Patchwork target-ppc: Change default machine for 64-bit

login
register
mail settings
Submitter David Gibson
Date May 17, 2013, 4:25 a.m.
Message ID <1368764711-13763-1-git-send-email-david@gibson.dropbear.id.au>
Download mbox | patch
Permalink /patch/244493/
State New
Headers show

Comments

David Gibson - May 17, 2013, 4:25 a.m.
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(-)
Benjamin Herrenschmidt - May 17, 2013, 4:36 a.m.
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.
David Gibson - May 17, 2013, 5:17 a.m.
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.
Peter Maydell - May 17, 2013, 7:17 a.m.
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
Alexander Graf - May 17, 2013, 7:22 a.m.
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
Andreas Färber - May 17, 2013, 7:42 a.m.
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,
>
Benjamin Herrenschmidt - May 17, 2013, 8:01 a.m.
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,
> > 
> 
>
Alexander Graf - June 13, 2013, 1:49 p.m.
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
Anthony Liguori - June 13, 2013, 6:31 p.m.
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
Scott Wood - June 13, 2013, 6:44 p.m.
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
Anthony Liguori - June 13, 2013, 7:02 p.m.
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
Peter Maydell - June 13, 2013, 8:44 p.m.
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
Andreas Färber - June 14, 2013, 2:28 p.m.
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
Andreas Färber - June 14, 2013, 4:15 p.m.
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
Benjamin Herrenschmidt - June 14, 2013, 9:58 p.m.
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.
David Gibson - June 16, 2013, 10:20 a.m.
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.

Patch

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,