Re: [Qemu-devel] [PATCH 17/25] spapr: add a sPAPRXive object to the machine

[David Gibson]

On Fri, Dec 01, 2017 at 09:10:24AM +0100, Cédric Le Goater wrote:
> On 12/01/2017 05:14 AM, David Gibson wrote:
> > On Thu, Nov 30, 2017 at 03:15:09PM +0000, Cédric Le Goater wrote:
> >> On 11/30/2017 05:55 AM, David Gibson wrote:
> >>> On Thu, Nov 23, 2017 at 02:29:47PM +0100, Cédric Le Goater wrote:
> >>>> The XIVE object is designed to be always available, so it is created
> >>>> unconditionally on newer machines.
> >>>
> >>> There doesn't actually seem to be anything dependent on machine
> >>> version here.
> >>
> >> No. I thought that was too early in the patchset. This is handled 
> >> in the last patch with a 'xive_exploitation' bool which is set to 
> >> false on older machines. 
> >>
> >> But, nevertheless, the XIVE objects are always created even if not
> >> used. Something to discuss.
> > 
> > That'll definitely break backwards migration, since the destination
> > won't understand the (unused but still present) xive state it
> > receives. 
> 
> no because it's not sent. the vmstate 'needed' op of the sPAPRXive
> object discards it :
> 
>     static bool vmstate_spapr_xive_needed(void *opaque)
>     {
>         sPAPRMachineState *spapr = SPAPR_MACHINE(qdev_get_machine());
>  
>         return spapr->xive_exploitation;
>     }

Ah, sorry, missed that.  Once we have negotiation we'll need to make
sure the xive_exploitation bit is sent first, of course, but I'm
pretty sure the machine state is already sent first.

> > So xives can only be created on new machine types. 
> 
> That would be better I agree. I can probably use the 'xive_exploitation'
> bool to condition its creation.

Hrm.  I'm less sure about that - I'm not sure the lifetimes line up.
But I'd like to avoid creating them on earlier machine types, even if
xive_exploitation can't do the trick.

> 
> > I'm ok
> > (at least tentatively) with always creating them on the newer machine
> > types, regardless of whether the guest ends up exploiting it or not.
> 
> OK.
> 
> 
> >>>> Depending on the configuration and
> >>>> the guest capabilities, the CAS negotiation process will decide which
> >>>> interrupt model to use, legacy or XIVE.
> >>>>
> >>>> The XIVE model makes use of the full range of the IRQ number space
> >>>> because the IRQ numbers for the CPU IPIs are allocated in the range
> >>>> below XICS_IRQ_BASE, which is unused by XICS.
> >>>
> >>> Ok.  And I take it 4096 is enough space for the XIVE IPIs for the
> >>> forseeable future?
> >>
> >> The biggest real system I am aware of as 16 sockets, 192 cores, SMT8. 
> >> That's 1536 cpus. pseries has a max_cpus of 1024.
> > 
> > Ok, so we can go to double the current system size, but not 4x.  Not
> > sure if that seems adequate or not.  Still it's a relatively minor
> > detail.
> > 
> 

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

signature.asc
Description: PGP signature