[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] KVM "fake DAX" flushing interface - discussion

From: Paolo Bonzini
Subject: Re: [Qemu-devel] KVM "fake DAX" flushing interface - discussion
Date: Thu, 23 Nov 2017 17:28:05 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]