From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54463) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZzoDV-0002Oo-Jt for qemu-devel@nongnu.org; Fri, 20 Nov 2015 11:07:18 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZzoDS-000458-6j for qemu-devel@nongnu.org; Fri, 20 Nov 2015 11:07:17 -0500 Received: from mx1.redhat.com ([209.132.183.28]:57392) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZzoDS-00044y-1i for qemu-devel@nongnu.org; Fri, 20 Nov 2015 11:07:14 -0500 From: Markus Armbruster Date: Fri, 20 Nov 2015 17:07:08 +0100 Message-ID: <87si401wpf.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain Subject: [Qemu-devel] ivshmem property size should be a size, not a string List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: marcandre.lureau@redhat.com, Claudio Fontana , Luiz Capitulino Everybody's favourite device model has "size" property. It's declared as *string* DEFINE_PROP_STRING("size", IVShmemState, sizearg), which gets converted to a size manually in the realize method: } else if (s->sizearg == NULL) { s->ivshmem_size = 4 << 20; /* 4 MB default */ } else { char *end; int64_t size = qemu_strtosz(s->sizearg, &end); if (size < 0 || *end != '\0' || !is_power_of_2(size)) { error_setg(errp, "Invalid size %s", s->sizearg); return; } s->ivshmem_size = size; } This is *wrong*. Impact, as far as I can tell: * -device ivshmem,help shows the property as 'str' instead of 'size'. Unhelpful, but hardly show-stopper. * On the command line and in HMP, ivshmem's size is parsed differently than other size properties. In particular, a number without a suffix is normally interpreted as bytes, except for ivshmem, where it's Mebibytes. Ugly inconsistency, but hardly the only one. * In QMP, the size must be given as JSON string instead of JSON number, and size suffixes are accepted. Example: "size": "512k" instead of "size": 524288. Right now, this violation of QMP rules is tolerable (barely), because device_add breaks some of these rules already. However, one goal of the current work on QAPI is to support a QMP command to plug devices that doesn't break QMP rules, and then this violation will stand out. Therefore, I want it fixed now, before ivshmem gets used in anger. A straight fix of size isn't fully backwards compatible: suffixes no longer work in QMP, and you need to use an 'M' suffix to get Mebibytes on command line and HMP. If that's unacceptable, we'll have to provide a new, fixed property, and deprecate size. Opinions?