linux-kernel - Re: [Qemu-devel] [RFC 2/2] KVM: add virtio-pmem driver

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:   Thu, 19 Oct 2017 11:21:26 -0700
From:   Dan Williams <dan.j.williams@...el.com>
To:     Christoph Hellwig <hch@...radead.org>
Cc:     Stefan Hajnoczi <stefanha@...il.com>,
        Pankaj Gupta <pagupta@...hat.com>,
        Kevin Wolf <kwolf@...hat.com>,
        haozhong zhang <haozhong.zhang@...el.com>,
        Jan Kara <jack@...e.cz>,
        xiaoguangrong eric <xiaoguangrong.eric@...il.com>,
        KVM list <kvm@...r.kernel.org>,
        David Hildenbrand <david@...hat.com>,
        linux-nvdimm <linux-nvdimm@...1.01.org>,
        ross zwisler <ross.zwisler@...el.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Qemu Developers <qemu-devel@...gnu.org>,
        Linux MM <linux-mm@...ck.org>,
        Stefan Hajnoczi <stefanha@...hat.com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Nitesh Narayan Lal <nilal@...hat.com>
Subject: Re: [Qemu-devel] [RFC 2/2] KVM: add virtio-pmem driver

On Thu, Oct 19, 2017 at 1:01 AM, Christoph Hellwig <hch@...radead.org> wrote:
> On Wed, Oct 18, 2017 at 08:51:37AM -0700, Dan Williams wrote:
>> This use case is not "Persistent Memory". Persistent Memory is
>> something you can map and make persistent with CPU instructions.
>> Anything that requires a driver call is device driver managed "Shared
>> Memory".
>
> How is this any different than the existing nvdimm_flush()? If you
> really care about the not driver thing it could easily be a write
> to a doorbell page or a hypercall, but in the end that's just semantics.

The difference is that nvdimm_flush() is not mandatory, and that the
platform will automatically perform the same flush at power-fail.
Applications should be able to assume that if they are using MAP_SYNC
that no other coordination with the kernel or the hypervisor is
necessary.

Advertising this as a generic Persistent Memory range to the guest
means that the guest could theoretically use it with device-dax where
there is no driver or filesystem sync interface. The hypervisor will
be waiting for flush notifications and the guest will just issue cache
flushes and sfence instructions. So, as far as I can see we need to
differentiate this virtio-model from standard "Persistent Memory" to
the guest and remove the possibility of guests/applications making the
wrong assumption.

Non-ODP RDMA in a guest comes to mind...