[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC QEMU PATCH v4 03/10] hostmem-xen: add a host memory backend for Xen
On Wed, Feb 28, 2018 at 03:56:54PM +0800, Haozhong Zhang wrote: > On 02/27/18 16:41 +0000, Anthony PERARD wrote: > > On Thu, Dec 07, 2017 at 06:18:05PM +0800, Haozhong Zhang wrote: > > > @@ -108,7 +109,10 @@ void pc_dimm_memory_plug(DeviceState *dev, > > > MemoryHotplugState *hpms, > > > } > > > > > > memory_region_add_subregion(&hpms->mr, addr - hpms->base, mr); > > > - vmstate_register_ram(vmstate_mr, dev); > > > + /* memory-backend-xen is not backed by RAM. */ > > > + if (!xen_enabled()) { > > > > Is it possible to have the same condition as the one used in > > host_memory_backend_memory_complete? i.e. base on whether the memory > > region is mapped or not (backend->mr.ram_block). > > Like "if (!xen_enabled() || backend->mr.ram_block))"? No, it will mute > the abortion (vmstate_register_ram --> qemu_ram_set_idstr ) caused by > the case that !backend->mr.ram_block in the non-xen environment. In non-xen environment, vmstate_register_ram() will be called, because !xen_enabled() is true, it would not matter if there is a ram_block or not. But if there is a memory-backend that can run in a xen environment that have a ram_block, vmstate_register_ram would not be called in the origial patch, but if we use (!xen_enabled() || vmstate_mr->ram_block) as condition then vmstate_register_ram will be called. Is this make sense? > > > + vmstate_register_ram(vmstate_mr, dev); > > > + } > > > numa_set_mem_node_id(addr, memory_region_size(mr), dimm->node); > > > > > > out: -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |