On Tue, Jul 20, 2021 at 08:51:04AM +0200, Pankaj Gupta wrote: > > > > > > > > - virtio_cread_le(vpmem->vdev, struct virtio_pmem_config, > > > > - start, &vpmem->start); > > > > - virtio_cread_le(vpmem->vdev, struct virtio_pmem_config, > > > > - size, &vpmem->size); > > > > + /* Retrieve the pmem device's address and size. It may have > > > > been supplied > > > > + * as a PCI BAR-relative shared memory region, or as a guest > > > > absolute address. > > > > + */ > > > > + have_shm_region = virtio_get_shm_region(vpmem->vdev, > > > > &pmem_region, > > > > + > > > > VIRTIO_PMEM_SHMCAP_ID_PMEM_REGION); > > > > > > Current implementation of Virtio pmem device in Qemu does not expose > > > it as PCI BAR. > > > So, can't test it. Just curious if device side implementation is also > > > tested for asynchronous > > > flush case? > > > > > > Thanks, > > > Pankaj > > > > Yes, I tested the async flush case as well. We basically call > > FlushFileBuffers on the backing file, which is Windows' equivalent of > > fsync. I also briefly tested with qemu to ensure that still works with > > the patch. > > Thank you for the confirmation. This sounds really good. > I am also getting back to pending items for virtio-pmem. > > On a side question: Do you guys have any or plan for Windows guest > implementation > for virtio-pmem?
Unfortunately, my team doesn't currently have any plans to add a Windows virtio-pmem implementation. My team is primarily focused on virtualization in client environments, which is a little different than server environments. For our Windows-based scenarios, dynamically sized disks are important. It's tricky to get that to work with pmem+DAX given that Windows isn't state separated.
