On 11/03/2016 10:49 PM, Igor Mammedov wrote:
On Thu, 3 Nov 2016 21:02:22 +0800
Xiao Guangrong <guangrong.x...@linux.intel.com> wrote:
On 11/03/2016 09:00 PM, Igor Mammedov wrote:
just drop this and describe properly 'len' in spec section
i.e. len: length of entire returned data (including the header)
Okay, i will change the spec like this:
QEMU Writes Output Data (based on the offset in the page):
[0x0 - 0x3]: 4 bytes, length of entire returned data
(including the header)
And drop the length field in Read_Fit return buffer, doc
the fit buffer like this:
+----------+--------+--------+-------------------------------------------+
| Field | Length | Offset |
Description |
+----------+--------+--------+-------------------------------------------+
you need to add length here, otherwise this table is not correct
Ah, so i am confused.
struct NvdimmFuncReadFITOut definition is based on the layout of
Read_FI output. You suggested to drop the length filed in
NvdimmFuncReadFITOut but keep it in the layout, it is not consistent.
I missed something?
+struct NvdimmFuncReadFITOut {
+ /* the size of buffer filled by QEMU. */
+ uint32_t len;
+ uint32_t func_ret_status; /* return status code. */
+ uint8_t fit[0]; /* the FIT data. */
+} QEMU_PACKED;
--------------------------------
| field | len | off | desc...
--------------------------------
| length | 4 | 0 | ....
--------------------------------
| status | 4 | 4 | ....
--------------------------------
| fit data | ................
i.e. you were forgetting to add length in spec so offsets were wrong
even for described fields.
We can not do this.
@len is used by QEMU emulation to count the size of the buffer that
_DSM should return. It's only used in NVDIMM_COMMON_DSM method which
is shared by the DSM method from VM and Read_Fit.
