From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59967) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zhf3W-0001w1-Pa for qemu-devel@nongnu.org; Thu, 01 Oct 2015 10:41:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zhf3V-0008DH-Ny for qemu-devel@nongnu.org; Thu, 01 Oct 2015 10:41:58 -0400 Received: from mx1.redhat.com ([209.132.183.28]:37833) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zhf3V-0008DA-HJ for qemu-devel@nongnu.org; Thu, 01 Oct 2015 10:41:57 -0400 References: <1443701677-13629-1-git-send-email-markmb@redhat.com> <1443701819-13855-1-git-send-email-markmb@redhat.com> <1443701819-13855-3-git-send-email-markmb@redhat.com> From: Laszlo Ersek Message-ID: <560D4631.9030109@redhat.com> Date: Thu, 1 Oct 2015 16:41:53 +0200 MIME-Version: 1.0 In-Reply-To: <1443701819-13855-3-git-send-email-markmb@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v4 2/7] fw_cfg DMA interface documentation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?UTF-8?Q?Marc_Mar=c3=ad?= , qemu-devel@nongnu.org Cc: "Gabriel L. Somlo" , Stefan Hajnoczi , Drew , Kevin O'Connor , Gerd Hoffmann On 10/01/15 14:16, Marc Mar=C3=AD wrote: > Add fw_cfg DMA interface specification in the documentation. >=20 > Based on Gerd Hoffman's initial implementation. >=20 > Signed-off-by: Marc Mar=C3=AD > Reviewed-by: Peter Maydell > --- > docs/specs/fw_cfg.txt | 65 +++++++++++++++++++++++++++++++++++++++++++= ++++---- > 1 file changed, 61 insertions(+), 4 deletions(-) >=20 > diff --git a/docs/specs/fw_cfg.txt b/docs/specs/fw_cfg.txt > index 5bc7b96..2d6b2da 100644 > --- a/docs/specs/fw_cfg.txt > +++ b/docs/specs/fw_cfg.txt > @@ -76,6 +76,13 @@ increasing address order, similar to memcpy(). > =20 > Selector Register IOport: 0x510 > Data Register IOport: 0x511 > +DMA Address IOport: 0x514 > + > +=3D=3D=3D ARM Register Locations =3D=3D=3D > + > +Selector Register address: Base + 8 (2 bytes) > +Data Register address: Base + 0 (8 bytes) > +DMA Address address: Base + 16 (8 bytes) > =20 > =3D=3D Firmware Configuration Items =3D=3D > =20 > @@ -86,11 +93,12 @@ by selecting the "signature" item using key 0x0000 = (FW_CFG_SIGNATURE), > and reading four bytes from the data register. If the fw_cfg device is > present, the four bytes read will contain the characters "QEMU". > =20 > -=3D=3D=3D Revision (Key 0x0001, FW_CFG_ID) =3D=3D=3D > +=3D=3D=3D Revision / feature bitmap (Key 0x0001, FW_CFG_ID) =3D=3D=3D > =20 > -A 32-bit little-endian unsigned int, this item is used as an interface > -revision number, and is currently set to 1 by QEMU when fw_cfg is > -initialized. > +A 32-bit little-endian unsigned int, this item is used to check for en= abled > +features. > + - Bit 0: traditional interface. Always set. > + - Bit 1: DMA interface. > =20 > =3D=3D=3D File Directory (Key 0x0019, FW_CFG_FILE_DIR) =3D=3D=3D > =20 > @@ -132,6 +140,55 @@ Selector Reg. Range Usage > In practice, the number of allowed firmware configuration items is giv= en > by the value of FW_CFG_MAX_ENTRY (see fw_cfg.h). > =20 > +=3D Guest-side DMA Interface =3D > + > +If bit 1 of the feature bitmap is set, the DMA interface is present. T= his does > +not replace the existing fw_cfg interface, it is an add-on. This inter= face > +can be used through the 64-bit wide address register. > + > +The address register is in big-endian format. The value for the regist= er is 0 > +at startup and after an operation. A write to the lower half triggers = an suggest "least significant half (at offset 4)" in place of "lower half" > +operation. This means that operations with 32-bit addresses can be tri= ggered > +with just one write, whereas operations with 64-bit addresses can be > +triggered with one 64-bit write or two 32-bit writes, starting with th= e > +higher part. suggest "most significant half (at offset 0)" in place of "higher part". With those changes: Reviewed-by: Laszlo Ersek Thanks! Laszlo > + > +In this register, the physical address of a FWCfgDmaAccess structure i= n RAM > +should be written. This is the format of the FWCfgDmaAccess structure: > + > +typedef struct FWCfgDmaAccess { > + uint32_t control; > + uint32_t length; > + uint64_t address; > +} FWCfgDmaAccess; > + > +The fields of the structure are in big endian mode, and the field at t= he lowest > +address is the "control" field. > + > +The "control" field has the following bits: > + - Bit 0: Error > + - Bit 1: Read > + - Bit 2: Skip > + - Bit 3: Select. The upper 16 bits are the selected index. > + > +When an operation is triggered, if the "control" field has bit 3 set, = the > +upper 16 bits are interpreted as an index of a firmware configuration = item. > +This has the same effect as writing the selector register. > + > +If the "control" field has bit 1 set, a read operation will be perform= ed. > +"length" bytes for the current selector and offset will be copied into= the > +physical RAM address specified by the "address" field. > + > +If the "control" field has bit 2 set (and not bit 1), a skip operation= will be > +performed. The offset for the current selector will be advanced "lengt= h" bytes. > + > +To check the result, read the "control" field: > + error bit set -> something went wrong. > + all bits cleared -> transfer finished successfully. > + otherwise -> transfer still in progress (doesn't happen > + today due to implementation not being asyn= c, > + but may in the future). > + > =3D Host-side API =3D > =20 > The following functions are available to the QEMU programmer for addin= g >=20