On Mon, 11 Mar 2019 21:44:22 +0100
Cédric Le Goater <c...@kaod.org> wrote:
> On 2/26/19 12:49 AM, David Gibson wrote:
> > On Fri, Feb 22, 2019 at 02:13:12PM +0100, Cédric Le Goater wrote:
> >> All is in place for KVM now. State synchronization and migration will
> >> come next.
> >
> > As with the kernel side capability, this should be moved later in the
> > series to avoid breaking bisections.
>
> I am not sure to understand. At this stage of the patchset, the XIVE
> exploitation mode is operational. We can not synchronise the state
> or migrate but it runs.
>
> Should we move XIVE activation after the migration patch ?
>
Yes because we do support migration of the spapr machine. Someone who wants
to track a migration issue on a XIVE based setup should be able to bisect,
without being affected by this series.
> C.
>
>
> >>
> >> Signed-off-by: Cédric Le Goater <c...@kaod.org>
> >> ---
> >> hw/ppc/spapr_irq.c | 9 ---------
> >> 1 file changed, 9 deletions(-)
> >>
> >> diff --git a/hw/ppc/spapr_irq.c b/hw/ppc/spapr_irq.c
> >> index 6e1c36dc62ca..1ad57582a403 100644
> >> --- a/hw/ppc/spapr_irq.c
> >> +++ b/hw/ppc/spapr_irq.c
> >> @@ -263,19 +263,10 @@ sPAPRIrq spapr_irq_xics = {
> >> static void spapr_irq_init_xive(sPAPRMachineState *spapr, int nr_irqs,
> >> Error **errp)
> >> {
> >> - MachineState *machine = MACHINE(spapr);
> >> uint32_t nr_servers = spapr_max_server_number(spapr);
> >> DeviceState *dev;
> >> int i;
> >>
> >> - /* KVM XIVE device not yet available */
> >> - if (kvm_enabled()) {
> >> - if (machine_kernel_irqchip_required(machine)) {
> >> - error_setg(errp, "kernel_irqchip requested. no KVM XIVE
> >> support");
> >> - return;
> >> - }
> >> - }
> >> -
> >> dev = qdev_create(NULL, TYPE_SPAPR_XIVE);
> >> qdev_prop_set_uint32(dev, "nr-irqs", nr_irqs);
> >> /*
> >
>
