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

Re: [Xen-devel] [RFC Design Doc] Add vNVDIMM support for Xen

>>> On 08.03.16 at 10:15, <haozhong.zhang@xxxxxxxxx> wrote:
> More thoughts on reserving NVDIMM space for per-page structures
> Currently, a per-page struct for managing mapping of NVDIMM pages may
> include following fields:
> struct nvdimm_page
> {
>     uint64_t mfn;        /* MFN of SPA of this NVDIMM page */
>     uint64_t gfn;        /* GFN where this NVDIMM page is mapped */
>     domid_t  domain_id;  /* which domain is this NVDIMM page mapped to */
>     int      is_broken;  /* Is this NVDIMM page broken? (for MCE) */
> }
> Its size is 24 bytes (or 22 bytes if packed). For a 2 TB NVDIMM,
> nvdimm_page structures would occupy 12 GB space, which is too hard to
> fit in the normal ram on a small memory host. However, for smaller
> NVDIMMs and/or hosts with large ram, those structures may still be able
> to fit in the normal ram. In the latter circumstance, nvdimm_page
> structures are stored in the normal ram, so they can be accessed more
> quickly.

Not sure how you came to the above structure - it's the first time
I see it, yet figuring out what information it needs to hold is what
this design process should be about. For example, I don't see why
it would need to duplicate M2P / P2M information. Nor do I see why
per-page data needs to hold the address of a page (struct
page_info also doesn't). And whether storing a domain ID (rather
than a pointer to struct domain, as in struct page_info) is the
correct think is also to be determined (rather than just stated).

Otoh you make no provisions at all for any kind of ref counting.
What if a guest wants to put page tables into NVDIMM space?

Since all of your calculations are based upon that fixed assumption
on the structure layout, I'm afraid they're not very meaningful
without first settling on what data needs tracking in the first place.


Xen-devel mailing list



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