From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52168) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YJ5tn-0007rU-0M for qemu-devel@nongnu.org; Wed, 04 Feb 2015 14:46:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YJ5tj-0008PK-2h for qemu-devel@nongnu.org; Wed, 04 Feb 2015 14:46:06 -0500 Received: from e06smtp13.uk.ibm.com ([195.75.94.109]:38285) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YJ5ti-0008Ou-Pv for qemu-devel@nongnu.org; Wed, 04 Feb 2015 14:46:02 -0500 Received: from /spool/local by e06smtp13.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 4 Feb 2015 19:46:00 -0000 Received: from b06cxnps3075.portsmouth.uk.ibm.com (d06relay10.portsmouth.uk.ibm.com [9.149.109.195]) by d06dlp02.portsmouth.uk.ibm.com (Postfix) with ESMTP id 5E7412190023 for ; Wed, 4 Feb 2015 19:45:54 +0000 (GMT) Received: from d06av06.portsmouth.uk.ibm.com (d06av06.portsmouth.uk.ibm.com [9.149.37.217]) by b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t14JjwMN8978858 for ; Wed, 4 Feb 2015 19:45:58 GMT Received: from d06av06.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av06.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t14EfgLv031925 for ; Wed, 4 Feb 2015 09:41:43 -0500 Message-ID: <54D276F4.7050400@de.ibm.com> Date: Wed, 04 Feb 2015 20:45:56 +0100 From: Christian Borntraeger MIME-Version: 1.0 References: <1423064635-19045-1-git-send-email-marcel@redhat.com> In-Reply-To: <1423064635-19045-1-git-send-email-marcel@redhat.com> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 0/8] machine: query machine properties rather than qemu opts List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Marcel Apfelbaum , qemu-devel@nongnu.org Cc: peter.maydell@linaro.org, peter.crosthwaite@xilinx.com, james.hogan@imgtec.com, mst@redhat.com, jan.kiszka@siemens.com, agraf@suse.de, cornelia.huck@de.ibm.com, scottwood@freescale.com, pbonzini@redhat.com, leon.alrae@imgtec.com, aurelien@aurel32.net Am 04.02.2015 um 16:43 schrieb Marcel Apfelbaum: > Commit e79d5a6 ("machine: remove qemu_machine_opts global list") removed option > descriptions from the -machine QemuOptsList to avoid repeating MachineState's QOM properties. > > This results in a Qemu crash if a non string option is queried using qemu opts. > Fix this by querying machine properties through designated wrappers. > > I hope I didn't miss anything. > Comments are appreciated as always. > > Thanks, > Marcel > > Marcel Apfelbaum (8): > machine: query iommu machine property rather than qemu opts > hw/machine: kernel-irqchip property support for allowed/required > machine: query kernel-irqchip machine property rather than qemu opts > kvm: add machine state to kvm_arch_init > machine: query kvm-shadow-mem machine property rather than qemu opts > machine: query phandle-start machine property rather than qemu opts > machine: query dump-guest-core machine property rather than qemu opts > machine: query mem-merge machine property rather than qemu opts In general this seems to work. I have a question, though: What I like is a way to do some wrappers in the specific machines. For example, we plan to add static inline void s390_machine_initfn(Object *obj) { object_property_add_bool(obj, "aes-key-wrap", machine_get_aes_key_wrap, machine_set_aes_key_wrap, NULL); object_property_set_description(obj, "aes-key-wrap", "enable/disable AES key wrapping using the CPACF wrapping key", NULL); object_property_add_bool(obj, "dea-key-wrap", machine_get_dea_key_wrap, machine_set_dea_key_wrap, NULL); object_property_set_description(obj, "dea-key-wrap", "enable/disable DEA key wrapping using the CPACF wrapping key", NULL); } Previously we used if (qemu_opt_get_bool(opts, "aes-key-wrap", false)) if target-s390/kvm.c to query that. Now, these options are pretty specific to s390 and adding them to hw/core/machine.c to create wrappers seems strange. So implementing them in hw/s390/s390-virtio-ccw.c seems a much better place. Would a function there that does gets S390_CCW_MACHINE(current_machine)->aes_key_wrap considered ok, or do we need to pollute hw/core/machine.c with architecture specific options? Christian PS: The same is somewhat true for qemu-options.hx. Having such specific machine option in the global help offers room for improvement