On Tue, Oct 23, 2012 at 8:25 PM, Stefan Hajnoczi <stefanha@xxxxxxxxx> wrote: > On Fri, Sep 21, 2012 at 01:17:21PM +0200, Vasilis Liaskovitis wrote: >> +static void dimm_populate(DimmDevice *s) >> +{ >> + DeviceState *dev= (DeviceState*)s; >> + MemoryRegion *new = NULL; >> + >> + new = g_malloc(sizeof(MemoryRegion)); >> + memory_region_init_ram(new, dev->id, s->size); >> + vmstate_register_ram_global(new); >> + memory_region_add_subregion(get_system_memory(), s->start, new); >> + s->mr = new; >> +} >> + >> +static void dimm_depopulate(DimmDevice *s) >> +{ >> + assert(s); >> + vmstate_unregister_ram(s->mr, NULL); >> + memory_region_del_subregion(get_system_memory(), s->mr); >> + memory_region_destroy(s->mr); >> + s->mr = NULL; >> +} > > How is dimm hot unplug protected against callers who currently have RAM > mapped (from cpu_physical_memory_map())? > > Emulated devices call cpu_physical_memory_map() directly or indirectly > through DMA emulation code. The RAM pointer may be held for arbitrary > lengths of time, across main loop iterations, etc. > > It's not clear to me that it is safe to unplug a DIMM that has network > or disk I/O buffers, for example. We also need to be robust against > malicious guests who abuse the hotplug lifecycle. QEMU should never be > left with dangling pointers. > Not sure about the block layer. But I think those thread are already out of big lock, so there should be a MemoryListener to catch the RAM-unplug event, and if needed, bdrv_flush. Regards, pingfan > Stefan > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html