Re: [Qemu-ppc] [PATCH v6 2/4] spapr: introduce a fixed IRQ number space

[Greg Kurz]

On Wed, 1 Aug 2018 09:14:43 +0200
Cédric Le Goater <address@hidden> wrote:

> [ ... ]
> 
> >>> +typedef struct sPAPRMachineState sPAPRMachineState;
> >>> +  
> >>
> >> Old compilers (GCC < 4.6) might complain about 'redefinition of typedef' if
> >> some file, say hw/ppc/spapr.c, includes both this header and 
> >> "hw/ppc/xics.h".
> >> We had several build breaks detected by 'make address@hidden'...
> >> The correct way to address this would be to move the typedef to the
> >> "qemu/typedefs.h" header.
> >>
> >> This being said, address@hidden vanished with commit e7b3af81597,
> >> so I guess we don't support such old distros anymore, and we can live with
> >> duplicate typedefs.  
> 
> I have a rhel6 vm for such tests but QEMU now requires python3 and 
> glib-2.40 and maybe more stuff. I am not sure one can compile QEMU 3.1
> on rhel/centos 6 anymore :/
> 

Minimal Python version is 2.7 actually, but rhel6 only has 2.6.6.

Anyway, with these new requirements, I'm pretty sure we can't build QEMU
anymore with these distros... even though rhel 6 EOL is Nov. 2020.

> 
> [ ... ]
> 
> >>>      /* Release previous MSIs */
> >>>      if (msi) {
> >>> +        if (!SPAPR_MACHINE_GET_CLASS(spapr)->legacy_irq_allocation) {
> >>> +            spapr_irq_msi_free(spapr, msi->first_irq, msi->num);
> >>> +        }  
> >>
> >> SPAPR_MACHINE_GET_CLASS() does all the recursive type checking, and you
> >> call it three times. Even if this isn't a hot path, maybe cache this in
> >> an smc variable at the beginning of the function as we do pretty much
> >> everywhere else. Also this would give prettier code IMHO.  
> > 
> > I agree with Greg that this would be a nice improvement, but it can
> > wait until a followup.  
> 
> The sPAPR code base is very stable so it's not too much work to respin.
> FYI, most of the XIVE v4 patchset still applies without a change.
> 
> Tell me if you find any other issues and I will resend.
> 
> Thanks,
> 
> C.