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=-3.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no 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 3AED8C433DB for ; Wed, 6 Jan 2021 16:48:51 +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 9073623142 for ; Wed, 6 Jan 2021 16:48:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9073623142 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]:42214 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kxBzN-00057e-Ez for qemu-devel@archiver.kernel.org; Wed, 06 Jan 2021 11:48:49 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:57316) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kxBwg-0002md-Rr for qemu-devel@nongnu.org; Wed, 06 Jan 2021 11:46:02 -0500 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:23939) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.90_1) (envelope-from ) id 1kxBwV-0002dK-Ea for qemu-devel@nongnu.org; Wed, 06 Jan 2021 11:46:01 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1609951549; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=UaxV4H1Q8DEiFhs2A0eWteREY+B8chVFt3pmGyWlCnc=; b=N8s2y51lzTPP5ay1fQufxh/UeJCnR+fsNhvhBJAREiV2sHspdTRhdfqV+vM0L50sgNkAp7 fjJtjAlq1f7HCfWZCrOTccuvPYzcFbsljbfmM81OQwpSZfQp6XDOBa26O0/EVDPnlLRw6g J4S6jlj242Wmi7ANYzUf6Qx4w58UgC0= 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-191-B6-sH5sPOh6VZrshuN7_1w-1; Wed, 06 Jan 2021 11:45:47 -0500 X-MC-Unique: B6-sH5sPOh6VZrshuN7_1w-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 926641006C81 for ; Wed, 6 Jan 2021 16:45:46 +0000 (UTC) Received: from localhost (unknown [10.40.208.13]) by smtp.corp.redhat.com (Postfix) with ESMTP id 2B32860C95; Wed, 6 Jan 2021 16:45:43 +0000 (UTC) Date: Wed, 6 Jan 2021 17:45:42 +0100 From: Igor Mammedov To: Vitaly Kuznetsov Subject: Re: [PATCH 5/5] i386: provide simple 'hyperv=on' option to x86 machine types Message-ID: <20210106174542.496f9f6e@redhat.com> In-Reply-To: <87sg7egp73.fsf@vitty.brq.redhat.com> References: <20201119103221.1665171-1-vkuznets@redhat.com> <20201119103221.1665171-6-vkuznets@redhat.com> <20201216205202.GJ3140057@habkost.net> <20201218181340.5e398280@redhat.com> <87r1n0j20n.fsf@vitty.brq.redhat.com> <20210105000435.1cf4c6f6@redhat.com> <87lfd7iowi.fsf@vitty.brq.redhat.com> <20210105170312.32cf0e12@redhat.com> <87a6tnibv4.fsf@vitty.brq.redhat.com> <20210106141303.145790f7@redhat.com> <87sg7egp73.fsf@vitty.brq.redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=imammedo@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass client-ip=216.205.24.124; envelope-from=imammedo@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -29 X-Spam_score: -3.0 X-Spam_bar: --- X-Spam_report: (-3.0 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.252, 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_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable 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: Paolo Bonzini , Marcelo Tosatti , Eduardo Habkost , qemu-devel@nongnu.org Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Wed, 06 Jan 2021 14:38:56 +0100 Vitaly Kuznetsov wrote: > Igor Mammedov writes: > > > On Tue, 05 Jan 2021 17:31:43 +0100 > > Vitaly Kuznetsov wrote: > > > >> Igor Mammedov writes: > >> > >> > On Tue, 05 Jan 2021 12:50:05 +0100 > >> > > >> > I think there is a misunderstanding, idea was: > >> > > >> > cpu_initfn() { > >> > //current set > >> > cpu->default_hyperv_cpu_features = ACD > >> > } > >> > > >> > compat_props_5.1 { > >> > cpu.default_hyperv_cpu_features = AB > >> > } > >> > > >> > compat_props_5.2 { > >> > cpu.default_hyperv_cpu_features = ABC > >> > } > >> > > >> > >> ... > >> > >> > I was talking about CPU features/properties only, it doesn't apply to other devices. > >> > It makes sense for machine to have a knob to create onboard hyperv specific > >> > devices if there is any (do we have any?). > >> > > >> > If there aren't any currently, I wouldn't bother with machine knob > >> > and just use -cpu foo,hv_default=on or -device cpu,hv_default=on > >> > like any other cpu feature. > >> > > >> > >> We don't currently have any devices which are not 'CPU features' (in > >> QEMU terminology), however, we already have Vmbus and I can easily > >> imagine us implementing e.g. hartbeat/kvp/vss/... devices on top. We > >> *may* want to enable these 'automatically' and that's what make > >> '-machine' option preferable. It is, however, not a *must* right now and > >> we can indeed wait until these devices appear and be happy with > >> 'hv_default' -cpu option for now. We will, however, need to teach upper > >> layers about the change when/if it happens. > > > > which makes me think we are trying to bite something that we shouldn't. > > Do we really need this patch (QEMU knob) to magically enable subset of > > features and/or devices for a specific OS flavor? > > > > It's job of upper layers to abstract low level QEMU details in to coarse > > grained knobs (libvirt/virt-install/virt-manager/...). > > For example virt-install may know that it installing a specific Windows > > version, and can build a tailored for that OS configuration including > > needed hyperv CPU features and hyperv specific devices. > > (if I'm not mistaken libosinfo is used to get metadata for preferred > > configuration, so perhaps this should become a patch for that library > > and its direct users). > > > > What we actually lack is a documentation for preferred configuration > > in docs/hyperv.txt, currently it just enumerates possible features. > > We can just document a recommended 'best practices' there without > > putting it in QEMU code and let upper layers to do their job in > > the stack. > > The problem we're facing here is that when a new enlightenment is > implemented it takes forever to propagate to the whole stack. We don't It's true not only for Hyper-V, I guess it's price to pay for modular solution. > have any different recommendations for different Windows versions, > neither does genuine Hyper-V. The 'fine grained' mechanis we have just > contributes to the creation of various Frankenstein configurations > (which look nothing like real Hyper-V), people just google for 'Windows > KVM slow', add something to their scripts and this keeps propagating. That's why I mentioned lack of documentation. If someone manually configures QEMU, one should understand what they do enable and why or enlist help of virt-install and likes. > Every time I see a configuration with only a few 'hv_*' options I ask > 'why don't you enable the rest?' and I'm yet to receive an answer > different from 'hm, I don't know, I copied it from somewhere and it > worked'. If individual features are are composed by virt-install or other tools based on libosinfo data, then we don't have to maintain versioning of new default_set_features per machine type, which will only become worse if we include hv specific devices into it. Also with libosinfo approach, old machine types and old QEMU versions can also benefit from it without need to change whole stack. And no versioning is necessary since chosen config set is stored in domain XML at the moment VM is created. > Setting 'hv_*' options individually should be considered debug only. that's how cpu's features were designed, a helper knob on top is fine as long as it doesn't mess the way it used to work and preferably is build on top of existing features. PS: another wild idea how to implement it using '-machine hyperv=on', based on compat props idea: // replaces bit set in your version hv_default_set[] = "hv_feat1", "hv_feat2", ... }; // probably should be done before -cpu is parsed then if machine hyperv=on foreach in hv_default_set[] object_register_sugar_prop(hv_default_set[i], "on") PS2: my preferred approach is still -cpu hyperv=on, since it doesn't depend on order CLI is currently parsed (which is fragile thing), but rather on what user asked us to do with CPU.