On Wed, Mar 11, 2020 at 11:08:27PM -0700, Klaus Birkelund Jensen wrote: > On Mar 11 15:54, Andrzej Jakowski wrote: > > On 3/11/20 2:20 AM, Stefan Hajnoczi wrote: > > > Please try: > > > > > > $ git grep pmem > > > > > > backends/hostmem-file.c is the backend that can be used and the > > > pmem_persist() API can be used to flush writes. > > > > I've reworked this patch into hostmem-file type of backend. > > From simple tests in virtual machine: writing to PMR region > > and then reading from it after VM power cycle I have observed that > > there is no persistency.
Sounds like an integration bug. QEMU's NVDIMM emulation uses HostMemoryBackend and file contents survive guest reboot. If you would like help debugging this, please post a link to the code and the command-line that you are using. > > I guess that persistent behavior can be achieved if memory backend file > > resides on actual persistent memory in VMM. I haven't found mechanism to > > persist memory backend file when it resides in the file system on block > > storage. My original mmap + msync based solution worked well there. > > I believe that main problem with mmap was with "ifdef _WIN32" that made it > > platform specific and w/o it patchew CI complained. > > Is there a way that I could rework mmap + msync solution so it would fit > > into qemu design? > > > > Hi Andrzej, > > Thanks for working on this! > > FWIW, I have implemented other stuff for the NVMe device that requires > persistent storage (e.g. LBA allocation tracking for DULBE support). I > used the approach of adding an additional blockdev and simply use the > qemu block layer. This would also make it work on WIN32. And if we just > set bit 0 in PMRWBM and disable the write cache on the blockdev we > should be good on the durability requirements. > > Unfortunately, I do not see (or know, maybe Stefan has an idea?) an easy > way of using the MemoryRegionOps nicely with async block backend i/o. so > we either have to use blocking I/O or fire and forget aio. Or, we can > maybe keep bit 1 set in PMRWBM and force a blocking blk_flush on PMRSTS > read. QEMU's block layer does not support persistent memory semantics and doesn't support mmap. It's fine for storing state from device emulation code, but if the guest itself requires memory load/store access to the data then the QEMU block layer does not provide that. For PMR I think HostMemoryBackend is the best fit. Stefan
signature.asc
Description: PGP signature
