On Mon, 31 Oct 2016 17:23:31 +0800 Xiao Guangrong <guangrong.x...@linux.intel.com> wrote:
> On 10/31/2016 05:20 PM, Igor Mammedov wrote: > > On Sun, 30 Oct 2016 23:24:46 +0200 > > "Michael S. Tsirkin" <m...@redhat.com> wrote: > > > >> From: Xiao Guangrong <guangrong.x...@linux.intel.com> > >> > >> According to ACPI 6.0 spec, "Memory Device Physical Address > >> Region Base" in memdev is defined as "This field provides the > >> Device Physical Address base of the region". This field should > >> be zero in our case > > I'm not sure that it should be a zero, > > care to point source which tells that it should be zero? > > The spec says that this is the Device Physical Address, so that > it is the device internal address, it should be zero as we do not > reserve any thing in device internal and we do not have no memory > interleave. spec says (ACPI 6.1: 5.2.25.3 NVDIMM Region Mapping Structure): "NVDIMM Physical Address Region Base": "The base physical address within the NVDIMM of the NVDIMM region." and nothing more than that so it's hard to come to conclusion that it's internal address nor it is offset as you treat it here (structure has 'Region Offset' for that). However there is "NVDIMM Region Size" field "In bytes. The size of the NVDIMM region. If SPA Range Structure Index and Interleave Ways are both non-zero, this field shall match System Physical Address Range Length divided by Interleave Ways." matches SPA structure, which makes me think that "NVDIMM Physical Address Region Base" similarly should match "System Physical Address Range Base" from SPA. > Actually, this bug was exported when we were enabling nvdimm in > windows guest. since it's rather new technology there isn't guaranty that Windows got it right yet. If spec is not clear we should ask for clarification and in mean time look at existing hardware for example.
