Hi, Paolo! > From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo > Bonzini > From: Pavel Dovgalyuk <pavel.dovga...@ispras.ru> > > This patch postpones vapic_paddr initialization, which is performed > during migration. When vapic_paddr is synchronized within the migration > process, apic_common functions could operate with incorrect apic state, > if it hadn't loaded yet. This patch postpones the synchronization until > the virtual machine is started, ensuring that the whole virtual machine > state has been loaded. > > > +static int vapic_post_load(void *opaque, int version_id) > +{ > + VAPICROMState *s = opaque; > + > /* > * The old implementation of qemu-kvm did not provide the state > * VAPIC_STANDBY. Reconstruct it. > @@ -752,17 +776,8 @@ static int vapic_post_load(void *opaque, int version_id) > return -1; > } > } > - if (s->state == VAPIC_ACTIVE) { > - if (smp_cpus == 1) { > - run_on_cpu(first_cpu, do_vapic_enable, s); > - } else { > - zero = g_malloc0(s->rom_state.vapic_size); > - cpu_physical_memory_write(s->vapic_paddr, zero, > - s->rom_state.vapic_size); > - g_free(zero); > - } > - } > > + s->vmsentry = qemu_add_vm_change_state_handler(kvmvapic_vm_state_change, > s); > return 0;
I've tested this patch with replay. I enabled VM reset (which was previously disabled for replay) while loading the VM state and discovered the following problem. vapic_enable function in kvmapic.c retrieves cpu number with the get_kpcr_number() function. When cpu number is -1 vapic_enable exits and does not call apic_enable_vapic, which should setup vapic_paddr field. Without this call vapic_paddr remains initialized with default value and behavior of the virtual machine becomes different. Pavel Dovgalyuk
