On Tue, 2017-07-25 at 07:46 -0700, Dan Williams wrote:
> On Tue, Jul 25, 2017 at 7:27 AM, Pankaj Gupta <pagupta(a)redhat.com>
> > Looks like only way to send flush(blk dev) from guest to host with
> > nvdimm
> > is using flush hint addresses. Is this the correct interface I am
> > looking?
> > blkdev_issue_flush
> > submit_bio_wait
> > submit_bio
> > generic_make_request
> > pmem_make_request
> > ...
> > if (bio->bi_opf & REQ_FLUSH)
> > nvdimm_flush(nd_region);
> I would inject a paravirtualized version of pmem_make_request() that
> sends an async flush operation over virtio to the host. Don't try to
> use flush hint addresses for this, they don't have the proper
> semantics. The guest should be allowed to issue the flush and receive
> the completion asynchronously rather than taking a vm exist and
> blocking on that request.
That is my feeling, too. A slower IO device benefits
greatly from an asynchronous flush mechanism.
Thanks for all the suggestions!
Just want to summarize here(high level):
This will require implementing new 'virtio-pmem' device which presents
a DAX address range(like pmem) to guest with read/write(direct access)
& device flush functionality. Also, qemu should implement corresponding
support for flush using virtio.
All rights reversed