From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36233) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c2Ke1-0005D7-PU for qemu-devel@nongnu.org; Thu, 03 Nov 2016 12:13:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c2Kdw-0001gt-NO for qemu-devel@nongnu.org; Thu, 03 Nov 2016 12:13:37 -0400 Received: from mx1.redhat.com ([209.132.183.28]:37716) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c2Kdw-0001gO-Gg for qemu-devel@nongnu.org; Thu, 03 Nov 2016 12:13:32 -0400 Date: Thu, 3 Nov 2016 17:13:23 +0100 From: Igor Mammedov Message-ID: <20161103171323.7825e926@Igors-MacBook-Pro.local> In-Reply-To: References: <1478145090-11987-1-git-send-email-guangrong.xiao@linux.intel.com> <1478145090-11987-3-git-send-email-guangrong.xiao@linux.intel.com> <20161103125808.11857a35@nial.brq.redhat.com> <2f770790-f3e9-ce56-e11b-e9f7e73e7078@linux.intel.com> <20161103140015.5f07b009@nial.brq.redhat.com> <20161103154934.2a9321f7@Igors-MacBook-Pro.local> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v4 2/3] nvdimm acpi: introduce _FIT List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Xiao Guangrong Cc: pbonzini@redhat.com, gleb@kernel.org, mtosatti@redhat.com, stefanha@redhat.com, mst@redhat.com, rth@twiddle.net, ehabkost@redhat.com, dan.j.williams@intel.com, kvm@vger.kernel.org, qemu-devel@nongnu.org On Thu, 3 Nov 2016 22:53:43 +0800 Xiao Guangrong wrote: > > > On 11/03/2016 10:49 PM, Igor Mammedov wrote: > > On Thu, 3 Nov 2016 21:02:22 +0800 > > Xiao Guangrong 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. spec describes buffer layout independently from AML that uses it, so it should describe whole data structure. Then it's upto guest how to read this data, it could be QEMU generated AML (as it's here) or some other driver or even BIOS.