Re: KVM "fake DAX" flushing interface - discussion

> Yes, the GUID will specifically identify this range as "Virtio Shared > Memory" (or whatever name survives after a bikeshed debate). The > libnvdimm core then needs to grow a new region type that mostly > behaves the same as a "pmem" region, but drivers/nvdimm/pmem.c grows a > new flush interface to perform the host communication. Device-dax > would be disallowed from attaching to this region type, or we could > grow a new device-dax type that does not allow the raw device to be > mapped, but allows a filesystem mounted on top to manage the flush > interface. I am afraid it is not a good idea that a single SPA is used for multiple purposes. For the region used as "pmem" is directly mapped to the VM so that guest can freely access it without host's assistance, however, for the region used as "host communication" is not mapped to VM, so that it causes VM-exit and host gets the chance to do specific operations, e.g, flush cache. So we'd better distinctly define these two regions to avoid the unnecessary complexity in hypervisor.