On Wed, Jul 21, 2021 at 3:09 PM Taylor Stark <[email protected]> wrote: > > 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.
Pardon me for commenting on an old thread... What does "state separated" mean here? There's configuration flexibility in the driver to resize persistent memory namespaces.
