On 23/11/2017 17:14, Dan Williams wrote: > On Wed, Nov 22, 2017 at 8:05 PM, Xiao Guangrong > <xiaoguangrong.eric@xxxxxxxxx> wrote: >> >> >> On 11/22/2017 02:19 AM, Rik van Riel wrote: >> >>> We can go with the "best" interface for what >>> could be a relatively slow flush (fsync on a >>> file on ssd/disk on the host), which requires >>> that the flushing task wait on completion >>> asynchronously. >> >> >> I'd like to clarify the interface of "wait on completion >> asynchronously" and KVM async page fault a bit more. >> >> Current design of async-page-fault only works on RAM rather >> than MMIO, i.e, if the page fault caused by accessing the >> device memory of a emulated device, it needs to go to >> userspace (QEMU) which emulates the operation in vCPU's >> thread. >> >> As i mentioned before the memory region used for vNVDIMM >> flush interface should be MMIO and consider its support >> on other hypervisors, so we do better push this async >> mechanism into the flush interface design itself rather >> than depends on kvm async-page-fault. > > I would expect this interface to be virtio-ring based to queue flush > requests asynchronously to the host. Could we reuse the virtio-blk device, only with a different device id? Thanks, Paolo
