[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PULL 30/47] acpi nvdimm: fix device physical address b
From: |
Igor Mammedov |
Subject: |
Re: [Qemu-devel] [PULL 30/47] acpi nvdimm: fix device physical address base |
Date: |
Mon, 31 Oct 2016 14:30:36 +0100 |
On Mon, 31 Oct 2016 19:09:07 +0800
Xiao Guangrong <address@hidden> wrote:
> On 10/31/2016 06:56 PM, Igor Mammedov wrote:
> > On Mon, 31 Oct 2016 17:23:31 +0800
> > Xiao Guangrong <address@hidden> wrote:
> >
> >> On 10/31/2016 05:20 PM, Igor Mammedov wrote:
> >>> On Sun, 30 Oct 2016 23:24:46 +0200
> >>> "Michael S. Tsirkin" <address@hidden> wrote:
> >>>
> >>>> From: Xiao Guangrong <address@hidden>
> >>>>
> >>>> 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).
>
> I think it is clear as the spec says "_within_ the NVDIMM", it is
> even more clear than ACPI 6.0 (5.2.25.2 Memory Device to System Physical
> Address Range Mapping Structure), in that, it says:
> "In bytes. This field provides the Device Physical Address
> base of the region."
It would be less confusing if spec would say
"starting offset of NVDIMM region within the NVDIMM"
(at least that's how I read it now after looking at 6.0 and
NVDIMM_Namespace_Spec.pdf)
as "base physical address" is not defined/described in ACPI spec.
> In the namespace spec (http://pmem.io/documents/NVDIMM_Namespace_Spec.pdf),
> the explanation to DPA in page 9:
> "DIMM Physical Address: A memory address from a DIMM’s perspective,
> that is, the offset into the DIMM’s memory, starting
> with DPA zero
> as the lowest addressable byte of the DIMM.
- [Qemu-devel] [PULL 25/47] cryptodev: introduce an unified wrapper for crypto operation, (continued)
- [Qemu-devel] [PULL 25/47] cryptodev: introduce an unified wrapper for crypto operation, Michael S. Tsirkin, 2016/10/30
- [Qemu-devel] [PULL 26/47] virtio-crypto: using bh to handle dataq's requests, Michael S. Tsirkin, 2016/10/30
- [Qemu-devel] [PULL 27/47] virtio-crypto: add myself as virtio-crypto and cryptodev backends maintainer, Michael S. Tsirkin, 2016/10/30
- [Qemu-devel] [PULL 28/47] acpi nvdimm: fix wrong buffer size returned by DSM method, Michael S. Tsirkin, 2016/10/30
- [Qemu-devel] [PULL 29/47] acpi nvdimm: fix OperationRegion definition, Michael S. Tsirkin, 2016/10/30
- [Qemu-devel] [PULL 30/47] acpi nvdimm: fix device physical address base, Michael S. Tsirkin, 2016/10/30
[Qemu-devel] [PULL 31/47] acpi nvdimm: fix ARG3 conflict, Michael S. Tsirkin, 2016/10/30
[Qemu-devel] [PULL 32/47] acpi nvdimm: fix Arg6 usage, Michael S. Tsirkin, 2016/10/30
[Qemu-devel] [PULL 34/47] acpi nvdimm: rename result_size to dsm_out_buf_siz, Michael S. Tsirkin, 2016/10/30
[Qemu-devel] [PULL 33/47] nvdimm acpi: compile nvdimm acpi code arch-independently, Michael S. Tsirkin, 2016/10/30
[Qemu-devel] [PULL 35/47] nvdimm acpi: use common macros instead of magic names, Michael S. Tsirkin, 2016/10/30
[Qemu-devel] [PULL 36/47] nvdimm acpi: prebuild nvdimm devices for available slots, Michael S. Tsirkin, 2016/10/30
[Qemu-devel] [PULL 37/47] nvdimm acpi: introduce fit buffer, Michael S. Tsirkin, 2016/10/30