From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42520) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VljOT-00060t-Ot for qemu-devel@nongnu.org; Wed, 27 Nov 2013 12:59:26 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VljOO-00017d-PQ for qemu-devel@nongnu.org; Wed, 27 Nov 2013 12:59:21 -0500 Received: from mx1.redhat.com ([209.132.183.28]:48505) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VljOO-00017X-H1 for qemu-devel@nongnu.org; Wed, 27 Nov 2013 12:59:16 -0500 Message-ID: <529632E6.4040101@redhat.com> Date: Wed, 27 Nov 2013 10:59:02 -0700 From: Eric Blake MIME-Version: 1.0 References: <1385001528-12003-1-git-send-email-imammedo@redhat.com> <1385001528-12003-14-git-send-email-imammedo@redhat.com> In-Reply-To: <1385001528-12003-14-git-send-email-imammedo@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="vKdC7o0e2Er0MWv3eW3QroCA5uehJkjWQ" Subject: Re: [Qemu-devel] [PATCH 13/27] acpi: memory hotplug ACPI hardware implementation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Igor Mammedov , qemu-devel@nongnu.org Cc: peter.maydell@linaro.org, stefanha@redhat.com, stefanb@linux.vnet.ibm.com, hutao@cn.fujitsu.com, mst@redhat.com, mjt@tls.msk.ru, mdroth@linux.vnet.ibm.com, armbru@redhat.com, vasilis.liaskovitis@profitbricks.com, quintela@redhat.com, kraxel@redhat.com, aliguori@amazon.com, pbonzini@redhat.com, marcel.a@redhat.com, lcapitulino@redhat.com, chegu_vinod@hp.com, afaerber@suse.de This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --vKdC7o0e2Er0MWv3eW3QroCA5uehJkjWQ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 11/20/2013 07:38 PM, Igor Mammedov wrote: > - implements QEMU hardware part of memory hotplug protocol > described at "docs/specs/acpi_mem_hotplug.txt" > - handles only memory add notification event for now >=20 > Signed-off-by: Igor Mammedov > --- > +0xa00: > + read access: > + [0x0-0x3] Lo part of memory device phys address > + [0x4-0x7] Hi part of memory device phys address > + [0x8-0xb] Lo part of memory device size in bytes > + [0xc-0xf] Hi part of memory device size in bytes > + [0x14] highest memory hot-plug interface version supported by QE= MU Nothing about [0x10-0x13]? [Ah, I see you mention it later] > + [0x15] Memory device status fields > + bits: > + 1: device is enabled and may be used by guest > + 2: device insert event, used by ACPI BIOS to distinguish= > + device for which no device check event to OSPM was is= sued Why start at bit 1 instead of bit 0? Also, should you document that remaining bits (2-7) should be ignored on read? > + [0x16-0x17] reserved > + > + write access: > + [0x0-0x3] Memory device slot selector, selects active memory dev= ice. > + All following accesses to other registers in 0xaf80-0x= af97 > + region will read/store data from/to selected memory de= vice. > + [0x4-0x7] OST event code reported by OSPM > + [0x8-0xb] OST status code reported by OSPM > + [0x15] Memory device status fields Nothing about behavior of [0xc-0x14]? Is it an error to write there, or are the writes just ignored, or...? > + bits: > + 2: if set to 1 clears device insert event, set by ACPI B= IOS > + after it has sent device check event to OSPM for > + seleted memory device s/seleted/selected/ What must be written into the other bits? Must reserved bits be written as 0, or the user do a read-modify-write, or...? > + > +Selecting memory device slot beyond present range has no effect on pla= tform: > + - not documented above write accesses to memory hot-plug registers > + are ignored; Reads awkwardly. Better is: write accesses to memory hot-plug registers not documented above are igno= red > + - not documented above read accesses to memory hot-plug registers r= eturn 0xFF Similar awkward wording. > + case 0xc: /* Hi part of DIMM size */ > + val =3D object_property_get_int(OBJECT(mdev->dimm), "size", NU= LL) >> 32; > + break; > + case 0x10: /* node proximity for _PXM method */ > + val =3D object_property_get_int(OBJECT(mdev->dimm), "node", NU= LL); > + break; This wasn't documented. > + case 0x14: /* intf version */ > + val =3D 1; > + break; > + case 0x15: /* pack and return is_* fields */ > + val |=3D mdev->is_enabled ? 1 : 0; > + val |=3D mdev->is_inserting ? 2 : 0; This is bit 0 and 1, not bit 1 and 2. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --vKdC7o0e2Er0MWv3eW3QroCA5uehJkjWQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJSljLmAAoJEKeha0olJ0NqlqwIAIJ2mMV2nuF+K5pLJxR7x2L4 iRuOhL1rwTJnnRNjeX9eY+oHZpUiOYA9wi6KU8e7YO1VguxkOvZ7Wo1fuwTjQPM7 ltNVqHzAk4eXuOX3JEih2V1Ot+Q2g4kprNyZ2nh6j4kfcXNy31LEhVAjDcO0bNbE tEv5+qRz7fp/8/wLzsOiSfE25sLwI1v1tN1mF/8Ja+4QSIDHoQsjbheU5n6EKfjp TbPkxd8VCRRFlmk2rXd4QuiPoyx+FCyz5lFFYWSQxpKQ+yGkMGFSa+1qqyPZOPDb oI9YE/9fSwMcgelXdX4reoeLBydCSYmqgki4sAnaXNSasszEAprNTnsmB/K4ExY= =vmcL -----END PGP SIGNATURE----- --vKdC7o0e2Er0MWv3eW3QroCA5uehJkjWQ--