MIME-Version: 1.0
In-Reply-To: <57FE75520200007800116D27@prv-mh.provo.novell.com>
References: <57FCF26A02000078000F15E0@prv-mh.provo.novell.com>
 <CAPcyv4gD3JTq93ET0SAYOxyPO9c0RTkPKSQKqZLo_8KPn53TiA@mail.gmail.com>
 <20161011165811.GO19349@localhost.localdomain> <CAPcyv4jX_xzj=gz=tfoNMx0qFtyeKwqttzCE5GrOi6Kz5anhiQ@mail.gmail.com>
 <20161011183259.GA23193@localhost.localdomain> <CAPcyv4gSfJM4jso17HdrGzG=rgzmuYkyH024=H4CnfqqVdw+PA@mail.gmail.com>
 <20161011194810.GD25907@localhost.localdomain> <CAPcyv4hBzGJeR=6bxa+DEwPGQFSCBGsQ1S18GR+y5_MMq6+f4g@mail.gmail.com>
 <20161012103318.vq36ed5ebb5xxcom@hz-desktop> <57FE3B880200007800116A75@prv-mh.provo.novell.com>
 <20161012145826.wwxecoo4o3ypos5o@hz-desktop> <57FE75520200007800116D27@prv-mh.provo.novell.com>
From: Dan Williams <dan.j.williams@intel.com>
Date: Wed, 12 Oct 2016 08:42:14 -0700
Message-ID: <CAPcyv4jYekNQQnD39sE=HekxUAOgXCx3_c3GLjV7MDUnvrK0vQ@mail.gmail.com>
Subject: Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen
To: Jan Beulich <JBeulich@suse.com>
Cc: Haozhong Zhang <haozhong.zhang@intel.com>,
        Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
        Stefano Stabellini <stefano@aporeto.com>,
        Arnd Bergmann <arnd@arndb.de>, andrew.cooper3@citrix.com,
        David Vrabel <david.vrabel@citrix.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Xiao Guangrong <guangrong.xiao@linux.intel.com>,
        Ross Zwisler <ross.zwisler@linux.intel.com>,
        xen-devel@lists.xenproject.org,
        "linux-nvdimm@lists.01.org" <linux-nvdimm@ml01.01.org>,
        Boris Ostrovsky <boris.ostrovsky@oracle.com>,
        Juergen Gross <JGross@suse.com>,
        Johannes Thumshirn <jthumshirn@suse.de>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset=UTF-8
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2001
Lines: 39

On Wed, Oct 12, 2016 at 8:39 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 12.10.16 at 16:58, <haozhong.zhang@intel.com> wrote:
>> On 10/12/16 05:32 -0600, Jan Beulich wrote:
>>>>>> On 12.10.16 at 12:33, <haozhong.zhang@intel.com> wrote:
>>>> The layout is shown as the following diagram.
>>>>
>>>> +---------------+-----------+-------+----------+--------------+
>>>> | whatever used | Partition | Super | Reserved | /dev/pmem0p1 |
>>>> |  by kernel    |   Table   | Block | for Xen  |              |
>>>> +---------------+-----------+-------+----------+--------------+
>>>>                 \_____________________ _______________________/
>>>>                                   V
>>>>                              /dev/pmem0
>>>
>>>I have to admit that I dislike this, for not being OS-agnostic.
>>>Neither should there be any Xen-specific region, nor should the
>>>"whatever used by kernel" one be restricted to just Linux. What
>>>I could see is an OS-reserved area ahead of the partition table,
>>>the exact usage of which depends on which OS is currently
>>>running (and in the Xen case this might be both Xen _and_ the
>>>Dom0 kernel, arbitrated by a tbd protocol). After all, when
>>>running under Xen, the Dom0 may not have a need for as much
>>>control data as it has when running on bare hardware, for it
>>>controlling less (if any) of the actual memory ranges when Xen
>>>is present.
>>>
>>
>> Isn't this OS-reserved area still not OS-agnostic, as it requires OS
>> to know where the reserved area is?  Or do you mean it's not if it's
>> defined by a protocol that is accepted by all OSes?
>
> The latter - we clearly won't get away without some agreement on
> where to retrieve position and size of this area. I was simply
> assuming that such a protocol already exists.
>

No, we should not mix the struct page reservation that the Dom0 kernel
may actively use with the Xen reservation that the Dom0 kernel does
not consume.  Explain again what is wrong with the partition approach?