linux-kernel - Re: [Qemu-devel] [RFC v2 0/2] kvm "fake DAX" device flushing

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 4 Jun 2018 01:56:55 -0400 (EDT)
From:   Pankaj Gupta <pagupta@...hat.com>
To:     Igor Mammedov <imammedo@...hat.com>
Cc:     kwolf@...hat.com, haozhong zhang <haozhong.zhang@...el.com>,
        nilal@...hat.com, jack@...e.cz,
        xiaoguangrong eric <xiaoguangrong.eric@...il.com>,
        kvm@...r.kernel.org, riel@...riel.com, linux-nvdimm@...1.01.org,
        david@...hat.com, ross zwisler <ross.zwisler@...el.com>,
        linux-kernel@...r.kernel.org, qemu-devel@...gnu.org,
        hch@...radead.org, linux-mm@...ck.org, mst@...hat.com,
        stefanha@...hat.com, niteshnarayanlal@...mail.com,
        marcel@...hat.com, pbonzini@...hat.com,
        dan j williams <dan.j.williams@...el.com>,
        lcapitulino@...hat.com
Subject: Re: [Qemu-devel] [RFC v2 0/2] kvm "fake DAX" device flushing


Hi Igor,

> 
> [...]
> > - Qemu virtio-pmem device
> >   It exposes a persistent memory range to KVM guest which
> >   at host side is file backed memory and works as persistent
> >   memory device. In addition to this it provides virtio
> >   device handling of flushing interface. KVM guest performs
> >   Qemu side asynchronous sync using this interface.
> a random high level question,
> Have you considered using a separate (from memory itself)
> virtio device as controller for exposing some memory, async flushing.
> And then just slaving pc-dimm devices to it with notification/ACPI
> code suppressed so that guest won't touch them?

No.

> 
> That way it might be more scale-able, you consume only 1 PCI slot
> for controller vs multiple for virtio-pmem devices.

That sounds like a good suggestion. I will note it as an
enhancement once we have other concerns related to basic working 
of 'flush' interface addressed. Then probably we can work on
things 'need to optimize' with robust core flush functionality. 

BTW any sample code doing this right now in Qemu? 

> 
> 
> > Changes from previous RFC[1]:
> > 
> > - Reuse existing 'pmem' code for registering persistent
> >   memory and other operations instead of creating an entirely
> >   new block driver.
> > - Use VIRTIO driver to register memory information with
> >   nvdimm_bus and create region_type accordingly.
> > - Call VIRTIO flush from existing pmem driver.
> > 
> > Details of project idea for 'fake DAX' flushing interface is
> > shared [2] & [3].
> > 
> > Pankaj Gupta (2):
> >    Add virtio-pmem guest driver
> >    pmem: device flush over VIRTIO
> > 
> > [1] https://marc.info/?l=linux-mm&m=150782346802290&w=2
> > [2] https://www.spinics.net/lists/kvm/msg149761.html
> > [3] https://www.spinics.net/lists/kvm/msg153095.html
> > 
> >  drivers/nvdimm/region_devs.c     |    7 ++
> >  drivers/virtio/Kconfig           |   12 +++
> >  drivers/virtio/Makefile          |    1
> >  drivers/virtio/virtio_pmem.c     |  118
> >  +++++++++++++++++++++++++++++++++++++++
> >  include/linux/libnvdimm.h        |    4 +
> >  include/uapi/linux/virtio_ids.h  |    1
> >  include/uapi/linux/virtio_pmem.h |   58 +++++++++++++++++++
> >  7 files changed, 201 insertions(+)
> > 
> 
> 
>