On Mon, 31 Jul 2023 at 08:18, David Hildenbrand <da...@redhat.com> wrote: > > On 31.07.23 01:48, Gavin Shan wrote: > > Runs into core dump on arm64 and the backtrace extracted from the > > core dump is shown as below. It's caused by accessing @kvm_state which > > isn't initialized at that point due to commit 176d073029 ("hw/arm/virt: > > Use machine_memory_devices_init()"), where the machine's memory region > > is added ealier than before. > > s/ealier/earlier/ > > > > > main > > qemu_init > > configure_accelerators > > qemu_opts_foreach > > do_configure_accelerator > > accel_init_machine > > kvm_init > > virt_kvm_type > > virt_set_memmap > > machine_memory_devices_init > > memory_region_add_subregion > > memory_region_add_subregion_common > > memory_region_update_container_subregions > > memory_region_transaction_begin > > qemu_flush_coalesced_mmio_buffer > > kvm_flush_coalesced_mmio_buffer > > > > Fix it by initializing @kvm_state early. With this applied, no crash > > is observed on arm64.
> As an alternative, we might simply do nothing in > kvm_flush_coalesced_mmio_buffer(), in case kvm_state is not setup yet. > We don't have any notifier registered in that case. Yes, this seems better I think -- conceptually kvm_init() probably ought to first set up the accelerator state and then set kvm_state last, so that other code that looks at the kvm_state global either sees NULL or else a completely valid state, not a possibly half-initialised one. (We should probably also NULL the global in the error-exit path, though I imagine we're about to exit in that case.) Is somebody able to write/test a patch for that today? Ideally we'd fix this for tomorrow's rc... thanks -- PMM