From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39562) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c1brg-0005UJ-Og for qemu-devel@nongnu.org; Tue, 01 Nov 2016 12:24:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c1brd-0005Cz-JL for qemu-devel@nongnu.org; Tue, 01 Nov 2016 12:24:44 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48066) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c1brd-0005Cl-Bd for qemu-devel@nongnu.org; Tue, 01 Nov 2016 12:24:41 -0400 Date: Tue, 1 Nov 2016 17:24:36 +0100 From: Igor Mammedov Message-ID: <20161101172436.49016997@nial.brq.redhat.com> In-Reply-To: <1477672540-27952-4-git-send-email-guangrong.xiao@linux.intel.com> References: <1477672540-27952-1-git-send-email-guangrong.xiao@linux.intel.com> <1477672540-27952-4-git-send-email-guangrong.xiao@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: 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 Sat, 29 Oct 2016 00:35:39 +0800 Xiao Guangrong wrote: > _FIT is required for hotplug support, guest will inquire the updated > device info from it if a hotplug event is received >=20 > As FIT buffer is not completely mapped into guest address space, so a > new function, Read FIT whose UUID is UUID > 648B9CF2-CDA1-4312-8AD9-49C4AF32BD62, handle 0x10000, function index > is 0x1, is reserved by QEMU to read the piece of FIT buffer. The buffer > is concatenated before _FIT return >=20 > Refer to docs/specs/acpi-nvdimm.txt for detailed design >=20 > Signed-off-by: Xiao Guangrong > --- > docs/specs/acpi_nvdimm.txt | 58 ++++++++++++- > hw/acpi/nvdimm.c | 204 +++++++++++++++++++++++++++++++++++++++= +++++- > 2 files changed, 257 insertions(+), 5 deletions(-) >=20 > diff --git a/docs/specs/acpi_nvdimm.txt b/docs/specs/acpi_nvdimm.txt > index 0fdd251..4aa5e3d 100644 > --- a/docs/specs/acpi_nvdimm.txt > +++ b/docs/specs/acpi_nvdimm.txt > @@ -127,6 +127,58 @@ _DSM process diagram: > | result from the page | | | > +--------------------------+ +--------------+ > =20 > - _FIT implementation > - ------------------- > - TODO (will fill it when nvdimm hotplug is introduced) > +Device Handle Reservation > +------------------------- > +As we mentioned above, byte 0 ~ byte 3 in the DSM memory save NVDIMM dev= ice > +handle. The handle is completely QEMU internal thing, the values in range > +[0, 0xFFFF] indicate nvdimm device (O means nvdimm root device named NVD= R), > +other values are reserved by other purpose. > + > +Current reserved handle: > +0x10000 is reserved for QEMU internal DSM function called on the root > +device. Above part should go to section where 'handle' is defined, i.e. earlier in = the file: ACPI writes _DSM Input Data (based on the offset in the page): [0x0 - 0x3]: 4 bytes, NVDIMM Device Handle, 0 is reserved for NVDIMM Root device. > +QEMU internal use only _DSM function > +------------------------------------ > +UUID, 648B9CF2-CDA1-4312-8AD9-49C4AF32BD62, is reserved for QEMU internal > +DSM function. > + > +There is the function introduced by QEMU and only used by QEMU internal. > + > +1) Read FIT UUID 648B9CF2-CDA1-4312-8AD9-49C4AF32BD62 is reserved for Read_FIT DSM func= tion (private QEMU function) > + 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. _FIT method uses Read_FIT function to fetch NFIT structures blob from QEMU in 1 page sized increments which are then concatenated and returned as _FI= T method result. =20 > + > + Input parameters: > + Arg0 =E2=80=93 UUID {set to 648B9CF2-CDA1-4312-8AD9-49C4AF32BD62} > + Arg1 =E2=80=93 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 = | ^ field, s/Byte//, s/Byte// > + +----------+-------------+-------------+-----------------------------= ------+ > + | offset | 4 | 0 | the offset of FIT buffer = | offset in QEMU's NFIT structures blob to read from > + +----------+-------------+-------------+-----------------------------= ------+ > + > + Output: > + +----------+-------------+-------------+-----------------------------= ------+ > + | Filed | Byte Length | Byte Offset | Description = | > + +----------+-------------+-------------+-----------------------------= ------+ > + | | | | return status codes = | > + | | | | 0x100 indicates fit has be= en | > + | status | 4 | 0 | updated = | 0x100 - error caused by NFIT update while read by _FIT wasn't completed > + | | | | other follows Chapter 3 in D= SM | s/other follows/other codes follow/ > + | | | | Spec Rev1 = | > + +----------+-------------+-------------+-----------------------------= ------+ > + | fit data | Varies | 4 | FIT data = | > + | | | | = | > + +----------+-------------+-------------+-----------------------------= ------+ what does "Varies" mean, how would I know reading this how much data Read_F= IT should read from shared page? > + > + The FIT offset is maintained by the caller itself, probably is not necessary sentence, or specify a caller (for example OSPM) > current offset plugs ^^^^? > + the length returned by the function is the next offset we should read. > + When all the FIT data has been read out, zero length is returned. > + > + If it returns 0x100, OSPM should restart to read FIT (read from offse= t 0 > + again). [...] that's all for doc part, I'll do the code part later.