From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46364) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c1xog-0004Lp-PA for qemu-devel@nongnu.org; Wed, 02 Nov 2016 11:51:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c1xod-0007IF-Nd for qemu-devel@nongnu.org; Wed, 02 Nov 2016 11:51:06 -0400 Received: from mga14.intel.com ([192.55.52.115]:49064) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c1xod-0007I7-El for qemu-devel@nongnu.org; Wed, 02 Nov 2016 11:51:03 -0400 References: <1477672540-27952-1-git-send-email-guangrong.xiao@linux.intel.com> <1477672540-27952-4-git-send-email-guangrong.xiao@linux.intel.com> <20161101164120.GD5707@stefanha-x1.localdomain> From: Xiao Guangrong Message-ID: Date: Wed, 2 Nov 2016 23:42:18 +0800 MIME-Version: 1.0 In-Reply-To: <20161101164120.GD5707@stefanha-x1.localdomain> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH v3 3/4] nvdimm acpi: introduce _FIT List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: pbonzini@redhat.com, imammedo@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 11/02/2016 12:41 AM, Stefan Hajnoczi wrote: > On Sat, Oct 29, 2016 at 12:35:39AM +0800, Xiao Guangrong wrote: >> +1) Read FIT >> + As we only reserved one page for NVDIMM ACPI it is impossible to map the >> + whole FIT data to guest's address space. This function is used by _FIT >> + method to read a piece of FIT data from QEMU. >> + >> + Input parameters: >> + Arg0 – UUID {set to 648B9CF2-CDA1-4312-8AD9-49C4AF32BD62} >> + Arg1 – Revision ID (set to 1) >> + Arg2 - Function Index, 0x1 >> + Arg3 - A package containing a buffer whose layout is as follows: >> + >> + +----------+-------------+-------------+-----------------------------------+ >> + | Filed | Byte Length | Byte Offset | Description | > > s/Filed/Field/ > > The same applies below too. Will fix. > >> + +----------+-------------+-------------+-----------------------------------+ >> + | offset | 4 | 0 | the offset of FIT buffer | >> + +----------+-------------+-------------+-----------------------------------+ > > s/offset of FIT buffer/offset into FIT buffer/ will fix. > >> + >> + Output: >> + +----------+-------------+-------------+-----------------------------------+ >> + | Filed | Byte Length | Byte Offset | Description | >> + +----------+-------------+-------------+-----------------------------------+ >> + | | | | return status codes | >> + | | | | 0x100 indicates fit has been | >> + | status | 4 | 0 | updated | >> + | | | | other follows Chapter 3 in DSM | >> + | | | | Spec Rev1 | >> + +----------+-------------+-------------+-----------------------------------+ >> + | fit data | Varies | 4 | FIT data | >> + | | | | | >> + +----------+-------------+-------------+-----------------------------------+ >> + >> + The FIT offset is maintained by the caller itself, current offset plugs > > s/plugs/plus/ Yes, indeed. > >> +struct NvdimmFuncReadFITIn { >> + uint32_t offset; /* the offset of FIT buffer. */ > > s/offset of FIT buffer/offset into FIT buffer/ will fix. Thank you, Stefan!