On 09/02/2015 07:31 PM, Igor Mammedov wrote:
On Wed, 2 Sep 2015 18:36:43 +0800
Xiao Guangrong <address@hidden> wrote:
On 09/02/2015 05:58 PM, Igor Mammedov wrote:
On Fri, 14 Aug 2015 22:51:59 +0800
Xiao Guangrong <address@hidden> 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?
Configdata area is used to store nvdimm device's configuration, normally, it's
namespace info.
Currently, we chosen configdata located at the end of nvdimm's backend-memory
as it's easy to configure / use and configdata is naturally non-volatile and it
is like the layout on physical device.
However, using two separated backed-memory is okay, for example:
-object memory-backend-file,id=mem0,file=/storage/foo
-object memory-backend-file,id=mem1,file=/storage/bar
-device nvdimm,memdev=mem0,configdata=mem1
then configdata is written to a single backend.
Which one is better for you? :)
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?
The file specified by @file is something like a normal disk, like /dev/sda/,
host process can use whole space on it. If we want to directly pass it to guest,
we can specify 'configdata=false'. If we allow guest to 'partition' (create
namespace on) it then we use 'configdata=true' to reserve some space to store
its partition info (namesapce info).