From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.1 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 57844C63793 for ; Thu, 22 Jul 2021 08:20:01 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 1B52761241 for ; Thu, 22 Jul 2021 08:20:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1B52761241 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:38972 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m6Tw0-0005K2-8o for qemu-devel@archiver.kernel.org; Thu, 22 Jul 2021 04:20:00 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:57434) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m6TvI-0003yg-Ar for qemu-devel@nongnu.org; Thu, 22 Jul 2021 04:19:16 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:26804) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m6TvG-0001rC-Oy for qemu-devel@nongnu.org; Thu, 22 Jul 2021 04:19:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1626941953; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=B68atyballxrztp1XoefKlwX0TOtkdAO7Ow1bLeGiNE=; b=Q/MSrSJwIk3R6K1dupNlRvWjAM1jh7C2hFgzCLBrUzaCPCtXr2hBkQlTtzpQLgo11DVDBT LFsw9BpjxTWNwWtWHM/Kz6okb19NdmuHms5hmsS4lfLy3Vd/NR/Z/9bpeEMqf4hKYa++eV +Niau2skEzStEE2IXo0clgWRCO/6jyU= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-542-YXE2F5vCNyeyKZlodw_djw-1; Thu, 22 Jul 2021 04:19:12 -0400 X-MC-Unique: YXE2F5vCNyeyKZlodw_djw-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id A862680430C for ; Thu, 22 Jul 2021 08:19:11 +0000 (UTC) Received: from angien.pipo.sk (unknown [10.40.208.38]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 4A63960CA1; Thu, 22 Jul 2021 08:19:07 +0000 (UTC) Date: Thu, 22 Jul 2021 10:19:04 +0200 From: Peter Krempa To: Paolo Bonzini Subject: Re: [PULL 36/40] vl: switch -M parsing to keyval Message-ID: References: <20210706100141.303960-1-pbonzini@redhat.com> <20210706100141.303960-37-pbonzini@redhat.com> MIME-Version: 1.0 In-Reply-To: <20210706100141.303960-37-pbonzini@redhat.com> User-Agent: Mutt/2.0.7 (2021-05-04) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=pkrempa@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Received-SPF: pass client-ip=170.10.133.124; envelope-from=pkrempa@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: libvir-list@redhat.com, qemu-devel@nongnu.org Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" CC libvir-list On Tue, Jul 06, 2021 at 12:01:37 +0200, Paolo Bonzini wrote: > Switch from QemuOpts to keyval. This enables the introduction > of non-scalar machine properties, and JSON syntax in the future. > > For JSON syntax to be supported right now, we would have to > consider what would happen if string-based dictionaries (produced by > -M key=val) were to be merged with strongly-typed dictionaries > (produced by -M {'key': 123}). > > The simplest way out is to never enter the situation, and only allow one > -M option when JSON syntax is in use. However, we want options such as > -smp to become syntactic sugar for -M, and this is a problem; as soon > as -smp becomes a shortcut for -M, QEMU would forbid using -M '{....}' > together with -smp. Therefore, allowing JSON syntax right now for -M > would be a forward-compatibility nightmare and it would be impossible > anyway to introduce -M incrementally in tools. > > Instead, support for JSON syntax is delayed until after the main > options are converted to QOM compound properties. These include -boot, > -acpitable, -smbios, -m, -semihosting-config, -rtc and -fw_cfg. Once JSON > syntax is introduced, these options will _also_ be forbidden together > with -M '{...}'. > > Signed-off-by: Paolo Bonzini > --- > softmmu/vl.c | 315 ++++++++++++++++++++++++--------------------------- > 1 file changed, 146 insertions(+), 169 deletions(-) This patch breaks detection of certain machine options features in libvirt which were being detected from 'query-command-line-options'. I presume the change simply removed this from the output of query-command-line-options due to the historical cruft how the aforementioned command works. Unfortunately I didn't find any suitable replacement from what we are querying. The entries which we now lack detection are: { "machine", "mem-merge", QEMU_CAPS_MEM_MERGE }, { "machine", "aes-key-wrap", QEMU_CAPS_AES_KEY_WRAP }, { "machine", "dea-key-wrap", QEMU_CAPS_DEA_KEY_WRAP }, { "machine", "kernel_irqchip", QEMU_CAPS_MACHINE_KERNEL_IRQCHIP }, { "machine", "loadparm", QEMU_CAPS_LOADPARM }, Note that the oldest supported qemu version in libvirt is 2.11 at this point and all the above flags are included in 2.11 and later. This means we can theoretically remove the detection and always assume the flags in case when they are unlikely to be removed in the future. Alternatively if you can suggest an option how to detect this it will be welcome. Thanks Peter