On Wed, 2 Sep 2015 18:36:43 +0800 Xiao Guangrong <guangrong.x...@linux.intel.com> wrote:
> > > On 09/02/2015 05:58 PM, Igor Mammedov wrote: > > On Fri, 14 Aug 2015 22:51:59 +0800 > > Xiao Guangrong <guangrong.x...@linux.intel.com> wrote: > > > >> Introduce "pc-nvdimm" device and it has two parameters: > > Why do you use prefix "pc-", I suppose we potentially > > could use this device not only with x86 targets but with > > other targets as well. > > I'd just drop 'pc' prefix through out patchset. > > Yeah, the prefix is stolen from pc-dimm, will drop this > prefix as your suggestion. > > > > >> - @file, which is the backed memory file for NVDIMM device > > Could you try to split device into backend/frontend parts, > > like it's done with pc-dimm. As I understand it's preferred > > way to implement this kind of devices. > > Then you could reuse memory backends that we already have > > including file backend. > > I considered it too and Stefan, Paolo got the some idea in > V1's review, however: > > | However, file-based memory used by NVDIMM is special, it divides the file > | to two parts, one part is used as PMEM and another part is used to store > | NVDIMM's configure data. > | > | Maybe we can introduce "end-reserved" property to reserve specified size > | at the end of the file. Or create a new class type based on > | memory-backend-file (named nvdimm-backend-file) class to hide this magic > | thing? I'd go with separate backend/frontend idea. Question is if this config area is part backend or frontend? If we pass-through NVDIMM device do we need to set configdata=true and QEMU would skip building config structures and use structures that are already present on passed-through device in that place? > > Your idea? [...] -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
