> > On Tue, 2017-07-25 at 07:46 -0700, Dan Williams wrote: > > On Tue, Jul 25, 2017 at 7:27 AM, Pankaj Gupta <pagupta@xxxxxxxxxx> > > wrote: > > > > > > 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. Thanks, Pankaj > > -- > All rights reversed
