From patchwork Thu Jan 25 15:16:19 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Gerd Hoffmann X-Patchwork-Id: 10184227 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id ABFBD60383 for ; Thu, 25 Jan 2018 15:24:04 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 9AE6828AB4 for ; Thu, 25 Jan 2018 15:24:04 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 8F6DB28AC0; Thu, 25 Jan 2018 15:24:04 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 2D2F428AB4 for ; Thu, 25 Jan 2018 15:24:03 +0000 (UTC) Received: from localhost ([::1]:46251 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eejNj-00052N-3r for patchwork-qemu-devel@patchwork.kernel.org; Thu, 25 Jan 2018 10:24:03 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48808) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eejGO-0006rH-Iy for qemu-devel@nongnu.org; Thu, 25 Jan 2018 10:16:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eejGJ-00017q-TO for qemu-devel@nongnu.org; Thu, 25 Jan 2018 10:16:28 -0500 Received: from mx1.redhat.com ([209.132.183.28]:41922) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eejGJ-00016y-NZ for qemu-devel@nongnu.org; Thu, 25 Jan 2018 10:16:23 -0500 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 0866E780F0 for ; Thu, 25 Jan 2018 15:16:23 +0000 (UTC) Received: from sirius.home.kraxel.org (ovpn-116-227.ams2.redhat.com [10.36.116.227]) by smtp.corp.redhat.com (Postfix) with ESMTP id 0D9FE5EE1B; Thu, 25 Jan 2018 15:16:20 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 105F111AB6; Thu, 25 Jan 2018 16:16:19 +0100 (CET) Date: Thu, 25 Jan 2018 16:16:19 +0100 From: Gerd Hoffmann To: "Daniel P. Berrange" Message-ID: <20180125151619.mywrqtexyvqqlcxj@sirius.home.kraxel.org> References: <20180117164118.8510-1-berrange@redhat.com> <20180117164118.8510-5-berrange@redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20180117164118.8510-5-berrange@redhat.com> User-Agent: NeoMutt/20171215 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Thu, 25 Jan 2018 15:16:23 +0000 (UTC) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.132.183.28 Subject: Re: [Qemu-devel] [PATCH v7 4/4] hw: convert virtio-input-hid device to keycodemapdb X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Paolo Bonzini , qemu-devel@nongnu.org, "Michael S. Tsirkin" Errors-To: qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org Sender: "Qemu-devel" X-Virus-Scanned: ClamAV using ClamSMTP Hi, > If the guest OS reboots, or otherwise re-initializes the virt-input device, > it will read the new keycode bitmap. No matter how many keys are defined, > the config space has a fixed 128 byte bitmap. There is, however, a size > field defiend which says how many bytes in the bitmap are used. No. There is a size field saying how big the bitmap is. config space (as in: virtio device config space) is only as big as is actually needed, i.e. basically the highest set bit of the bitmap determines the config space size. Debug patch ... vinput->cfg_size); ... prints this without the patch ... virtio_input_device_realize: virtio-keyboard-device: 29 bytes cfg space ... and this with the patch: virtio_input_device_realize: virtio-keyboard-device: 37 bytes cfg space That seems to not have any bad side effects on live migration though. I can vmsave with unpatched qemu and vmload with patched qemu (and visa versa). Agreeing with the analysis that guests should cope with the change just fine, worst case being that the newly added keys are not working on updated qemu without guest reboot. So I think we can go forward with this one without breaking anything. thanks, Gerd --- a/hw/input/virtio-input.c +++ b/hw/input/virtio-input.c @@ -255,6 +255,8 @@ static void virtio_input_device_realize(DeviceState *dev, Error **errp) } vinput->cfg_size += 8; assert(vinput->cfg_size <= sizeof(virtio_input_config)); + fprintf(stderr, "%s: %s: %d bytes cfg space\n", __func__, + object_get_typename(OBJECT(dev)), vinput->cfg_size); virtio_init(vdev, "virtio-input", VIRTIO_ID_INPUT,