[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 11:56:44 +0100 |
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).
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.
- [Qemu-devel] [PULL 23/47] virtio-crypto: add control queue handler, (continued)
- [Qemu-devel] [PULL 23/47] virtio-crypto: add control queue handler, Michael S. Tsirkin, 2016/10/30
- [Qemu-devel] [PULL 24/47] virtio-crypto: add data queue processing handler, Michael S. Tsirkin, 2016/10/30
- [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