linux-kernel - Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen

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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAPcyv4hpmVU477vrAeJrcHpMS9qRSnRwY1T8FrPqAxZXMyLBOg@mail.gmail.com>
Date:   Thu, 13 Oct 2016 08:40:21 -0700
From:   Dan Williams <dan.j.williams@...el.com>
To:     Jan Beulich <JBeulich@...e.com>
Cc:     Haozhong Zhang <haozhong.zhang@...el.com>,
        Stefano Stabellini <stefano@...reto.com>,
        Arnd Bergmann <arnd@...db.de>, andrew.cooper3@...rix.com,
        David Vrabel <david.vrabel@...rix.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Xiao Guangrong <guangrong.xiao@...ux.intel.com>,
        Ross Zwisler <ross.zwisler@...ux.intel.com>,
        xen-devel@...ts.xenproject.org,
        "linux-nvdimm@...ts.01.org" <linux-nvdimm@...1.01.org>,
        Boris Ostrovsky <boris.ostrovsky@...cle.com>,
        Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
        Juergen Gross <JGross@...e.com>,
        Johannes Thumshirn <jthumshirn@...e.de>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen

On Thu, Oct 13, 2016 at 2:08 AM, Jan Beulich <JBeulich@...e.com> wrote:
[..]
>> I think we can do the similar for Xen, like to lay another pseudo
>> device on /dev/pmem and do the reservation, like 2. in my previous
>> reply.
>
> Well, my opinion certainly doesn't count much here, but I continue to
> consider this a bad idea. For entities like drivers it may well be
> appropriate, but I think there ought to be an independent concept
> of "OS reserved", and in the Xen case this could then be shared
> between hypervisor and Dom0 kernel. Or if we were to consider Dom0
> "just a guest", things should even be the other way around: Xen gets
> all of the OS reserved space, and Dom0 needs something custom.

You haven't made the case why Xen is special and other applications of
persistent memory are not.  The current struct page reservation
supports fundamental address-ability of persistent memory namespaces
for the rest of the kernel.  The Xen reservation is application
specific.  XFS, EXT4, and DM also have application specific usages of
persistent memory and consume metadata space out of a block device. If
we don't need an XFS-mode nvdimm device, why do we need Xen-mode?