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; } > 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. > 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. >