On Thu, 20 Oct 2016 11:56:10 -0200 Eduardo Habkost <ehabk...@redhat.com> wrote:
> On Thu, Oct 20, 2016 at 03:42:15PM +0200, Igor Mammedov wrote: > > On Thu, 20 Oct 2016 21:11:38 +0800 > > Haozhong Zhang <haozhong.zh...@intel.com> wrote: > > > > > On 10/20/16 14:34 +0200, Igor Mammedov wrote: > > > >On Thu, 20 Oct 2016 14:13:01 +0800 > > > >Haozhong Zhang <haozhong.zh...@intel.com> wrote: > > > > > > > >> If a file is used as the backend of memory-backend-file and its size is > > > >> not identical to the property 'size', the file will be truncated. For a > > > >> file used as the backend of vNVDIMM, its data is expected to be > > > >> persistent and the truncation may corrupt the existing data. > > > >I wonder if it's possible just skip 'size' property in your case instead > > > >'notrunc' property. That way if size is not present one'd get actual size > > > >using get_file_size() and set 'size' to it? > > > >And if 'size' is provided and 'size' != file_size then error out. > > > > > > > > > > I don't know how this can be implemented in QEMU. Specially, how does > > > the memory-backend-file know it's used for vNVDIMM, so that it can > > > skip the 'size' property? > > Does memory-backend-file needs to know that it's used by NVDIMM? > > Looking at nvdimm_realize it doesn't as it's assumes > > hostemem_size == pmem_size + label_size > > > > I'd make hostmem_file.size optional and take size from file > > and if 'size' is specified explictly require it to mach file size. > > It's generic and has nothing to do with nvdimm. > > We can take size from file, or take size from the > host_memory_backend_get_memory() callers. > > Enumerating all sizes that QEMU can use as input: > > A) Backend file size > B) memory backend "size" option > C) frontend-provided size (-numa size, -m, or pc-dimm "size" > property) -numa size affect only anon memory not backend backed one, for backend baked memory we use memdev where size comes from backend pc-dimm.size is readonly and isn't supposed to influence backend.size I'd drop C option > > My suggestion is: > * B should be optional. > * If B is omitted, we should never truncate the file to a smaller > size. i.e. derive backend.size from filesize if possible (i.e. not hugepages) > * If B is omitted, we can use C as the size when mapping the > file. frontend size is the size that's mapped into guest address space. it should not influence backend's size in backward direction. You may notice pc-dimm.size is not user settable (readonly) property. > * If B is omitted, and C > A, maybe we could use ftruncate() to > extend the file to make users happy. But I'm not sure we > should (I think B should be the only option that cause > truncation). > * If we want to make C optional on some cases, we could use A if > B is omitted. we shouldn't use C to manage backends behavior But I have a question why do we have truncation at all in place now. > > Does that make sense? >
