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

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Haozhong Zhang writes ("Re: [Xen-devel] [RFC Design Doc] Add vNVDIMM support 
for Xen"):
> On 02/18/16 21:14, Konrad Rzeszutek Wilk wrote:
> > [someone:]
> > > (2) For XENMAPSPACE_gmfn, _gmfn_range and _gmfn_foreign,
> > >    (a) never map idx in them to GFNs occupied by vNVDIMM, and
> > >    (b) never map idx corresponding to GFNs occupied by vNVDIMM
> > 
> > Would that mean that guest xen-blkback or xen-netback wouldn't
> > be able to fetch data from the GFNs? As in, what if the HVM guest
> > that has the NVDIMM also serves as a device domain - that is it
> > has xen-blkback running to service other guests?
> 
> I'm not familiar with xen-blkback and xen-netback, so following
> statements maybe wrong.
> 
> In my understanding, xen-blkback/-netback in a device domain maps the
> pages from other domains into its own domain, and copies data between
> those pages and vNVDIMM. The access to vNVDIMM is performed by NVDIMM
> driver in device domain. In which steps of this procedure that
> xen-blkback/-netback needs to map into GFNs of vNVDIMM?

I think I agree with what you are saying.  I don't understand exactly
what you are proposing above in XENMAPSPACE_gmfn but I don't see how
anything about this would interfere with blkback.

blkback when talking to an nvdimm will just go through the block layer
front door, and do a copy, I presume.

I don't see how netback comes into it at all.

But maybe I am just confused or ignorant!  Please do explain :-).

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel