[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC XEN PATCH v2 00/15] Add vNVDIMM support to HVM domains
On Tue, Apr 4, 2017 at 10:00 AM, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> wrote: > On Sat, Apr 01, 2017 at 08:45:45AM -0700, Dan Williams wrote: >> On Sat, Apr 1, 2017 at 4:54 AM, Konrad Rzeszutek Wilk <konrad@xxxxxxxxxx> >> wrote: >> > ..snip.. >> >> >> Is there a resource I can read more about why the hypervisor needs to >> >> >> have this M2P mapping for nvdimm support? >> >> > >> >> > M2P is basically an array of frame numbers. It's indexed by the host >> >> > page frame number, or the machine frame number (MFN) in Xen's >> >> > definition. The n'th entry records the guest page frame number that is >> >> > mapped to MFN n. M2P is one of the core data structures used in Xen >> >> > memory management, and is used to convert MFN to guest PFN. A >> >> > read-only version of M2P is also exposed as part of ABI to guest. In >> >> > the previous design discussion, we decided to put the management of >> >> > NVDIMM in the existing Xen memory management as much as possible, so >> >> > we need to build M2P for NVDIMM as well. >> >> > >> >> >> >> Thanks, but what I don't understand is why this M2P lookup is needed? >> > >> > Xen uses it to construct the EPT page tables for the guests. >> > >> >> Does Xen establish this metadata for PCI mmio ranges as well? What Xen >> > >> > It doesn't have that (M2P) for PCI MMIO ranges. For those it has an >> > ranges construct (since those are usually contingous and given >> > in ranges to a guest). >> >> So, I'm confused again. This patchset / enabling requires both M2P and >> contiguous PMEM ranges. If the PMEM is contiguous it seems you don't >> need M2P and can just reuse the MMIO enabling, or am I missing >> something? > > I think I am confusing you. > > The patchset (specifically 04/15] xen/x86: add XEN_SYSCTL_nvdimm_pmem_setup > to setup host pmem ) > adds a hypercall to tell Xen where on the NVDIMM it can put > the M2P array and as well the frametables ('struct page'). > > There is no range support. The reason is that if break up > an NVDIMM in various chunks (and then put a filesystem on top of it) - and > then figure out which of the SPAs belong to the file - and then > "expose" that file to a guest as NVDIMM - it's SPAs won't > be contingous. Hence the hypervisor would need to break down > the 'ranges' structure down in either a bitmap or an M2P > and also store it. This can get quite tricky so you may > as well just start with an M2P and 'struct page'. Ok... but the problem then becomes that the filesystem is free to change the file-offset to SPA mapping any time it wants. So the M2P support is broken if it expects static relationships. > The placement of those datastructures is " > v2 patch > series relies on users/admins in Dom0 instead of Dom0 driver to indicate > the > location to store the frametable and M2P of pmem. > " > > Hope this helps? It does, but it still seems we're stuck between either 1/ not needing M2P if we can pass a whole pmem-namespace through to the guest or 2/ M2P being broken by non-static file-offset to physical address mappings. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |