qemu-ppc
[Top][All Lists]
Advanced

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

Re: [Qemu-ppc] [RFC 9/9] spapr: Add pseries-2.6 machine type


From: David Gibson
Subject: Re: [Qemu-ppc] [RFC 9/9] spapr: Add pseries-2.6 machine type
Date: Wed, 2 Dec 2015 14:52:14 +1100
User-agent: Mutt/1.5.24 (2015-08-30)

On Tue, Dec 01, 2015 at 02:53:24PM +1100, Alexey Kardashevskiy wrote:
> On 12/01/2015 02:12 PM, David Gibson wrote:
> >On Tue, Dec 01, 2015 at 01:43:10PM +1100, Alexey Kardashevskiy wrote:
> >>On 11/30/2015 07:51 PM, David Gibson wrote:
> >>>Signed-off-by: David Gibson <address@hidden>
> >>>---
> >>>  hw/ppc/spapr.c | 16 +++++++++++++---
> >>>  1 file changed, 13 insertions(+), 3 deletions(-)
> >>>
> >>>diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> >>>index 3d31fe7..f680497 100644
> >>>--- a/hw/ppc/spapr.c
> >>>+++ b/hw/ppc/spapr.c
> >>>@@ -2334,9 +2334,9 @@ static const TypeInfo spapr_machine_info = {
> >>>      machine_init(spapr_machine_register_##suffix)
> >>>
> >>>  /*
> >>>- * pseries-2.5
> >>>+ * pseries-2.6
> >>>   */
> >>>-static void spapr_machine_2_5_class_compat(MachineClass *mc)
> >>>+static void spapr_machine_2_6_class_compat(MachineClass *mc)
> >>>  {
> >>>      sPAPRMachineClass *smc = SPAPR_MACHINE_CLASS(mc);
> >>>
> >>>@@ -2344,7 +2344,17 @@ static void 
> >>>spapr_machine_2_5_class_compat(MachineClass *mc)
> >>>      mc->desc = "pSeries Logical Partition (PAPR compliant)";
> >>>  }
> >>>
> >>>-DEFINE_SPAPR_MACHINE(2_5, "2.5", NULL, true);
> >>>+DEFINE_SPAPR_MACHINE(2_6, "2.6", NULL, true);
> >>>+
> >>>+/*
> >>>+ * pseries-2.5
> >>>+ */
> >>>+static void spapr_machine_2_5_class_compat(MachineClass *mc)
> >>>+{
> >>>+    spapr_machine_2_6_class_compat(mc);
> >>>+}
> >>>+
> >>>+DEFINE_SPAPR_MACHINE(2_5, "2.5", NULL, false);
> >>>
> >>>  /*
> >>>   * pseries-2.4
> >>>
> >>
> >>After this patch, "smc->dr_lmb_enabled = true" moved to
> >>spapr_machine_2_6_class_compat() from  spapr_machine_2_5_class_compat(), was
> >>that on purpose?
> >
> >Yes.  2.6 wants dr lmb enabled as well, which means 2.5 doesn't need
> >it because it calls the 2.6 function.  The significant part of the
> >history is where the 2.4 function turns if *off* again.
> 
> And then "smc->dr_lmb_enabled = true" will have to jump to new
> spapr_machine_2_7_class_compat() (or whatever version it will be by then)?
> Uff. ok.
> 
> I'd just understand it better if there was
> spapr_machine_default_class_init() which would set everything "on" and the
> latest default spapr_machine_X_Y_class_compat() would call it directly; the
> lower version class_init()s would call upper level (as the patchset does)
> and disable individual features.

Yeah, I had something like that in an earlier draft and decided it
wasn't worth it.  I think you've concinved me to change my mind again,
though.
 
> And spapr_machine_class_init() would only initialize class callbacks but not
> touch the features.

Hmm.. actually that's maybe a better approach - make
spapr_machine_class_init() take the place of
spapr_machine_default_class_init() but update it so it's actually
correct for the latest defaults, which it isn't right now.

-- 
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

Attachment: signature.asc
Description: PGP signature


reply via email to

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