Sure. Then, is there any real reason why the backing files should not be unlinked ?
-- - Thanks char * (*shesha) (uint64_t cache, uint8_t F00D) { return 0x0000C0DE; } From: "Michael S. Tsirkin" <mst at redhat.com<mailto:m...@redhat.com>> Date: Tuesday, September 29, 2015 at 9:16 AM To: Cisco Employee <shesha at cisco.com<mailto:shesha at cisco.com>> Cc: "Xie, Huawei" <huawei.xie at intel.com<mailto:huawei.xie at intel.com>>, "dev at dpdk.org<mailto:dev at dpdk.org>" <dev at dpdk.org<mailto:dev at dpdk.org>> Subject: Re: [dpdk-dev] Unlinking hugepage backing file after initialiation On Tue, Sep 29, 2015 at 03:48:08PM +0000, shesha Sreenivasamurthy (shesha) wrote: If huge pages are allocated for the guest and if the guest crashes there may be a chance that the new guest may not be able to get huge pages again as some other guest or process on the host used it. But I am not able to understand memory corruption you are talking about. In my opinion, if a process using a piece of memory goes away, it should not re-attach to the same piece of memory without running a sanity check on it. guest memory is allocated an freed by hypervisor, right? I don't think it's dpdk's job. -- MST