qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [PATCH 0/5] ARM virt: Add NVDIMM support


From: Shameerali Kolothum Thodi
Subject: RE: [PATCH 0/5] ARM virt: Add NVDIMM support
Date: Mon, 25 Nov 2019 13:20:02 +0000

Hi Eric/Igor,

> -----Original Message-----
> From: Shameerali Kolothum Thodi
> Sent: 22 October 2019 15:05
> To: 'Auger Eric' <address@hidden>; address@hidden;
> address@hidden; address@hidden
> Cc: address@hidden; address@hidden; xuwei (O)
> <address@hidden>; address@hidden; Linuxarm
> <address@hidden>
> Subject: RE: [PATCH 0/5] ARM virt: Add NVDIMM support
> 

[..]

> > one question: I noticed that when a NVDIMM slot is hotplugged one get
> > the following trace on guest:
> >
> > nfit ACPI0012:00: found a zero length table '0' parsing nfit
> > pmem0: detected capacity change from 0 to 1073741824
> >
> > Have you experienced the 0 length trace?
> 
> I double checked and yes that trace is there. And I did a quick check with
> x86 and it is not there.
> 
> The reason looks like, ARM64 kernel receives an additional 8 bytes size when
> the kernel evaluates the "_FIT" object.
> 
> For the same test scenario, Qemu reports a FIT buffer size of 0xb8 and
> 
> X86 Guest kernel,
> [    1.601077] acpi_nfit_init: data 0xffff8a273dc12b18 sz 0xb8
> 
> ARM64 Guest,
> [    0.933133] acpi_nfit_init: data 0xffff00003cbe6018 sz 0xc0
> 
> I am not sure how that size gets changed for ARM which results in
> the above mentioned 0 length trace. I need to debug this further.
> 
> Please let me know if you have any pointers...

I spend some time debugging this further and it looks like the AML code
behaves differently on x86 and ARM64.

Booted guest with nvdimm mem, and used SSDT override with dbg prints
added,

-object memory-backend-ram,id=mem1,size=1G \
-device nvdimm,id=dimm1,memdev=mem1 \

On X86,
-----------

[Qemu]NVDIMM:nvdimm_dsm_func_read_fit: Read FIT: offset 0 FIT size 0xb8 Dirty 
Yes.
[Qemu]NVDIMM:nvdimm_dsm_func_read_fit: read_fit_out buf size 0xc0 
func_ret_status 0

[AML]"NVDIMM-NCAL: Rcvd RLEN 000000C0"
[AML]"NVDIMM-NCAL: Creating OBUF with 000005E0 bits"
[AML]"NVDIMM-NCAL: Created  BUF(Local7) size 000000BC"
[AML]"NVDIMM-RFIT Rcvd buf size 000000BC"
[AML]"NVDIMM-RFIT Created NVDR.RFIT.BUFF size 000000B8"
[AML]"NVDIMM-FIT: Rcvd buf size 000000B8"

[Qemu]NVDIMM:nvdimm_dsm_func_read_fit: Read FIT: offset 0xb8 FIT size 0xb8 
Dirty No.
[Qemu]NVDIMM:nvdimm_dsm_func_read_fit: read_fit_out buf size 0x8 
func_ret_status 0 

[AML]"NVDIMM-NCAL: Rcvd RLEN 00000008"
[AML]"NVDIMM-NCAL: Creating OBUF with 00000020 bits"
[AML]"NVDIMM-NCAL: Created  BUF(Local7) size 00000004"
[AML]"NVDIMM-RFIT Rcvd buf size 00000004"
[AML]"NVDIMM-FIT: Rcvd buf size 00000000"
[AML]"NVDIMM-FIT: _FIT returned size 000000B8"

[ KERNEL] acpi_nfit_init: NVDIMM: data 0xffff9855bb9a7518 sz 0xb8  --> Guest 
receives correct size(0xb8) here 

On ARM64,
---------------

[Qemu]NVDIMM:nvdimm_dsm_func_read_fit: Read FIT: offset 0 FIT size 0xb8 Dirty 
Yes.
[Qemu]VDIMM:nvdimm_dsm_func_read_fit: read_fit_out buf size 0xc0 
func_ret_status 0 

[AML]"NVDIMM-NCAL: Rcvd RLEN 00000000000000C0"
[AML]"NVDIMM-NCAL: Creating OBUF with 00000000000005E0 bits"
[AML]"NVDIMM-NCAL: Created  BUF(Local7) size 00000000000000BC"
[AML]"NVDIMM-RFIT Rcvd buf size 00000000000000BC"
[AML]"NVDIMM-RFIT Created NVDR.RFIT.BUFF size 00000000000000B8"
[AML]"NVDIMM-FIT: Rcvd buf size 00000000000000B8"

[Qemu]NVDIMM:nvdimm_dsm_func_read_fit: Read FIT: offset 0xb8 FIT size 0xb8 
Dirty No.
[Qemu]NVDIMM:nvdimm_dsm_func_read_fit: read_fit_out buf size 0x8 
func_ret_status 0 

[AML]"NVDIMM-NCAL: Rcvd RLEN 0000000000000008"
[AML]"NVDIMM-NCAL: Creating OBUF with 0000000000000020 bits"  --> All looks 
same as x86 up to here.
[AML]"NVDIMM-NCAL: Created  BUF(Local7) size 0000000000000008"  ---> The size 
goes wrong. 8 bytes instead of 4!.
[AML]"NVDIMM-RFIT Rcvd buf size 0000000000000008"
[AML]"NVDIMM-RFIT Created NVDR.RFIT.BUFF size 0000000000000004"
[AML]"NVDIMM-FIT: Rcvd buf size 0000000000000008"  --> Again size goes wrong. 8 
bytes instead of 4!.

[Qemu]NVDIMM:nvdimm_dsm_func_read_fit: Read FIT: offset 0xc0 FIT size 0xb8 
Dirty No.  -->Another read is attempted 
[Qemu]NVDIMM:nvdimm_dsm_func_read_fit: read_fit_out buf size 0x8 
func_ret_status 3  --> Error status returned

[AML]"NVDIMM-NCAL: Rcvd RLEN 0000000000000008"
[AML]"NVDIMM-NCAL: Creating OBUF with 0000000000000020 bits"
[AML]"NVDIMM-NCAL: Created  BUF(Local7) size 0000000000000008"
[AML]"NVDIMM-FIT: Rcvd buf size 0000000000000000"
[AML]"NVDIMM-FIT: _FIT returned size 00000000000000C0"   --> Wrong size 
returned.
[ KERNEL] acpi_nfit_init: NVDIMM: data 0xffff0000fc57ce18 sz 0xc0   -->Kernel 
gets 0xc0 instead of 0xb8


It looks like the aml, "CreateField (ODAT, Zero, Local1, OBUF)" goes wrong for
ARM64 when the buffer is all zeroes. My knowledge on aml is very limited and not
sure this is a 32/64bit issue or not. I am attaching the SSDT files with the 
above
dbg prints added. Could you please take a look and let me know what actually is
going on here...

Much appreciated,
Shameer.


Attachment: SSDT-dbg-arm64.dsl
Description: SSDT-dbg-arm64.dsl

Attachment: SSDT-dbg-x86.dsl
Description: SSDT-dbg-x86.dsl


reply via email to

[Prev in Thread] Current Thread [Next in Thread]