On 23/11/2017 17:14, Dan Williams wrote:
On Wed, Nov 22, 2017 at 8:05 PM, Xiao Guangrong
> 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
> 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
> 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?