[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [RFC XEN PATCH v4 00/41] Add vNVDIMM support to HVM domains



On 02/13/18 15:39 +0000, Roger Pau Monné wrote:
> On Tue, Feb 13, 2018 at 06:40:20AM -0700, Jan Beulich wrote:
> > >>> On 13.02.18 at 12:13, <roger.pau@xxxxxxxxxx> wrote:
> > > On Tue, Feb 13, 2018 at 04:05:45AM -0700, Jan Beulich wrote:
> > >> >>> On 13.02.18 at 11:29, <roger.pau@xxxxxxxxxx> wrote:
> > >> > On Tue, Feb 13, 2018 at 03:06:24AM -0700, Jan Beulich wrote:
> > >> >> >>> On 12.02.18 at 11:05, <roger.pau@xxxxxxxxxx> wrote:
> > >> >> > If you map the NVDIMM as MMIO to Dom0 you don't need the M2P entries
> > >> >> > IIRC, and if it's mapped using 1GB pages it shouldn't use that much
> > >> >> > memory for the page tables (ie: you could just use normal RAM for 
> > >> >> > the
> > >> >> > page tables that map the NVDIMM IMO). Of course that only applies to
> > >> >> > PVH/HVM.
> > >> >> 
> > >> >> But in order to use (part of) it in a RAM-like manner we need struct
> > >> >> page_info for it.
> > >> > 
> > >> > I guess the main use of this would be to grant NVDIMM pages? And
> > >> > without a page_info that's not possible.
> > >> 
> > >> Why grant? Simply giving such a page as RAM to a guest would
> > >> already be a problem without struct page_info (as then we can't
> > >> track the page owner, nor can we refcount the page).
> > > 
> > > My point was to avoid doing that, and always assign the pages as
> > > MMIO, which IIRC doesn't require a struct page_info.
> > 
> > MMIO pages can't be used for things like page tables, because of
> > the refcounting that's needed. The page being like RAM, however,
> > implies that the guest needs to be able to use it as anything a RAM
> > page can be used for.
> 
> OK, I'm quite unsure about what people actually use NVDIMM for, I
> thought it was mostly used as some kind of storage, but if it's
> actually used as plain RAM then yes, we likely need struct page_info
> for them, which is a PITA.
> 
> My worries are that if you boot bare metal Linux and use NVDIMM, and
> then reboot into Xen you won't be able to access the NVDIMM data
> anymore AFAICT because Xen will have taken over it, and already used
> part of it to store it's own page tables, which is problematic IMO.
> 

The page tables for NVDIMM whose size is not large are still kept in
RAM.

This patchset does not let Xen use any NVDIMM at boot time, just
because of your worries. Part 2 of this patchset introduces a set of
xl subcommands to allow users to educate Xen after boot up which parts
of NVDIMM can be safely used by Xen without corrupting the real useful
data. That is, I suppose users to pre-partition the NVDIMM (before
using it with Xen) to at least two parts, one for hypervisor
management purpose and the data in it does not need to preserve across
power cycles, and others for user data which may need to be
non-volatile.

Haozhong

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.