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 9FFFCC433E0 for ; Tue, 5 Jan 2021 16:33:46 +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 1619F22CA2 for ; Tue, 5 Jan 2021 16:33:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1619F22CA2 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]:40286 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kwpHF-0006hQ-5v for qemu-devel@archiver.kernel.org; Tue, 05 Jan 2021 11:33:45 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:60094) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kwpFR-00057p-G7 for qemu-devel@nongnu.org; Tue, 05 Jan 2021 11:31:53 -0500 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:52350) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.90_1) (envelope-from ) id 1kwpFO-0002rJ-23 for qemu-devel@nongnu.org; Tue, 05 Jan 2021 11:31:53 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1609864308; 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=W0VfzyBbOlOCRdXuLKrtAQ0dRwyMuEKYFOhrnd4jhA0=; b=idBT+B/C8F6SDl6gle/58UQUUg1ILBE4qXMH08uNSmwbqr0GokZw6zLAes7jv2R9gffvLQ k9NGtRD0XzH0SJh3ugi6dppTKSwUmBq6W4bVYnyHWv84y8QovOZ9vZVztGOcxpCCfkToqC LO+RX/KxYSccmPILg1RIWod1xi5N+ho= 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-577-_xNbjnDJOSujwZgJxVPGuQ-1; Tue, 05 Jan 2021 11:31:46 -0500 X-MC-Unique: _xNbjnDJOSujwZgJxVPGuQ-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 3764C1842142 for ; Tue, 5 Jan 2021 16:31:45 +0000 (UTC) Received: from localhost (unknown [10.40.208.13]) by smtp.corp.redhat.com (Postfix) with ESMTP id 89C252B394; Tue, 5 Jan 2021 16:31:43 +0000 (UTC) Date: Tue, 5 Jan 2021 17:31:41 +0100 From: Igor Mammedov To: Eduardo Habkost Subject: Re: [PATCH 5/5] i386: provide simple 'hyperv=on' option to x86 machine types Message-ID: <20210105173141.2fafe61b@redhat.com> In-Reply-To: <20210105143431.GL18467@habkost.net> 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> <20210104182906.GD18467@habkost.net> <20210105003650.71f39045@redhat.com> <20210105143431.GL18467@habkost.net> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 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=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: Paolo Bonzini , Vitaly Kuznetsov , Marcelo Tosatti , qemu-devel@nongnu.org Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Tue, 5 Jan 2021 09:34:31 -0500 Eduardo Habkost wrote: > On Tue, Jan 05, 2021 at 12:36:50AM +0100, Igor Mammedov wrote: > > On Mon, 4 Jan 2021 13:29:06 -0500 > > Eduardo Habkost wrote: > > > > > On Mon, Jan 04, 2021 at 01:54:32PM +0100, Vitaly Kuznetsov wrote: > > > > Igor Mammedov writes: > > > > > > > > >> > > > > > >> > + /* Hyper-V features enabled with 'hyperv=on' */ > > > > >> > + x86mc->default_hyperv_features = BIT(HYPERV_FEAT_RELAXED) | > > > > >> > + BIT(HYPERV_FEAT_VAPIC) | BIT(HYPERV_FEAT_TIME) | > > > > >> > + BIT(HYPERV_FEAT_CRASH) | BIT(HYPERV_FEAT_RESET) | > > > > >> > + BIT(HYPERV_FEAT_VPINDEX) | BIT(HYPERV_FEAT_RUNTIME) | > > > > >> > + BIT(HYPERV_FEAT_SYNIC) | BIT(HYPERV_FEAT_STIMER) | > > > > >> > + BIT(HYPERV_FEAT_FREQUENCIES) | BIT(HYPERV_FEAT_REENLIGHTENMENT) | > > > > >> > + BIT(HYPERV_FEAT_TLBFLUSH) | BIT(HYPERV_FEAT_EVMCS) | > > > > >> > + BIT(HYPERV_FEAT_IPI) | BIT(HYPERV_FEAT_STIMER_DIRECT); > > > > > I'd argue that feature bits do not belong to machine code at all. > > > > > If we have to involve machine at all then it should be a set property/value pairs > > > > > that machine will set on CPU object (I'm not convinced that doing it > > > > > from machine code is good idea though). > > > > > > > > > > > > > These are 'features' and not feature bits. 'Bits' here are just our > > > > internal (to QEMU) representation of which features are enable and which > > > > are not, we could've just used booleans instead. These feature, when > > > > enabled, will result in some CPUID changes (not 1:1) but I don't see how > > > > it's different from > > > > > > > > " -machine q35,accel=kvm " > > > > > > > > which also results in CPUID changes. > > > > > > This is a good point, although having accel affect CPUID bits was > > > also a source of complexity for query-cpu-model-expansion and > > > other QMP queries. > > > > why was, it's still a headache (mutating CPU models depending on accelerator) > > > > > > > > > > > > > The main reason for putting this to x86 machine type is versioning, as > > > > we go along we will (hopefully) be implementing more and more Hyper-V > > > > features but we want to provide 'one knob to rule them all' but do it in > > > > a way that will allow migration. We already have 'hv_passthrough' for > > > > CPU. > > > > > > I agree completely that the set of bits needs to be on > > > MachineClass. We just need to agree on the external interface. > > That's where I disagree, > > let me exaggerate for demo purpose: > > - let's move all CPU models feature defaults to MachineClass and forget about compat properties > > since in that case we can opencode changes in machine_class_init > > I don't see your point here. compat_props is also part of > MachineClass. they are but compat_props are data and we typically use them for keeping old behavior for devices, all it needs is adding a line to set old property value. While class_init is typically used for altering machine specific behavior, sure it can be used to patch up device but that's a bit more ugly (need to add a field to MachineClass to key off and the somehow wire it up to affected device). > > > > It's rather hard code integration between device models, which we try > > to avoid and still refactoring QEMU code to get rid of it. > > (sure it works until it's not and someone else need to rewrite half of QEMU > > to accomplish it's own task because we mixed things together) > > I don't see why using a X86CPU-specific API that is not based on > QOM properties is hard code integration. compat_props is not the > only allowed API for machines to communicate with devices. > > > > > > > > > > > > > > >> > > > > > >> > + if (x86ms->hyperv_enabled) { > > > > >> > + feat = x86mc->default_hyperv_features; > > > > >> > + /* Enlightened VMCS is only available on Intel/VMX */ > > > > >> > + if (!cpu_has_vmx(&cpu->env)) { > > > > >> > + feat &= ~BIT(HYPERV_FEAT_EVMCS); > > > > >> > + } > > > > >> > + > > > > >> > + cpu->hyperv_features |= feat; > > > > > that will ignore features user explicitly doesn't want, > > > > > ex: > > > > > -machine hyperv=on -cpu foo,hv-foo=off > > > > > > > > > > > > > Existing 'hv_passthrough' mode can also affect the result. Personally, I > > > > don't see where 'hv-foo=off' is needed outside of debugging and these > > > > use-cases can probably be covered by explicitly listing required > > > > features but I'm not against making this work, shouldn't be hard. > > > > > > I'm all for not wasting time supporting use cases that are not > > > necessary in practice. We just need to document the expected > > > behavior clearly, whatever we decide to do. > > > > documenting is good, but if it adds new semantics to how CPU features are handled > > users up the stack will need code it up as well and juggle with > > -machine + -cpu + -device cpu-foo > > not to mention poor developers who will have to figure out why we do > > set CPU properties in multiple different ways. > > > > however if we add it as CPU properties that behave the same way as other > > properties, all mgmt has to do is expose new property to user for usage. > > I think we need to be careful here. Sometimes just exposing the > QOM properties used to implemented a feature is not the best user > interface. e.g.: even if using compat_props for implementing the > hyperv features preset, that doesn't automatically mean we want > hyperv=on to be a -cpu option. > > I would even argue we shouldn't be focusing on implementation > details (like we are doing right now) until the desired external > interface is described clearly. > > > > > it even more true when building machine from QMP interface would be available, > > where we would want '-device foo' more or less the same way instead of > > special casing some of them, i.e. I'd rather have one device to configure, > > instead of doing it in multiple places. It's not possible in reality > > but for new code we should try to minimize split brain issues. > > Is split brain a practical problem here? If the new behavior is > implemented in x86_cpu_realizefn() or x86_cpu_pre_plug(), we know > it's going to affect all CPU objects. i was talking about user interface here, i.e.: (QMP) create_machine(hyperv=on) (QMP) device_add(cpu, hv_foo=x) vs: (QMP) device_add(cpu, hyperv_defaults=on,=onhv_foo=x) i.e. in the later case cpu specific options are consolidate within device stanza and mgmt doesn't need to be aware and split cpu config in to steps. > > > > > > > > > > > not sure we would like to introduce such invariant, > > > > > in normal qom property handling the latest set property should have effect > > > > > (all other invariants we have in x86 cpu property semantics are comming from legacy handling > > > > > and I plan to deprecate them (it will affect x86 and sparc cpus) so CPUs will behave like > > > > > any other QOM object when it come to property handling) > > > > > > > > > > anyways it's confusing a bit to have cpu flags to come from 2 different places > > > > > > > > > > -cpu hyperv-use-preset=on,hv-foo=off > > > > > > > > > > looks less confusing and will heave expected effect > > > > > > > > > > > > > Honestly, 'hyperv-use-preset' is confusing even to me :-) > > > > > > > > What if we for a second stop thinking about Hyper-V features being CPU > > > > features only, e.g. if we want to create Dynamic Memory or PTP or any > > > > other Hyper-V specific device in a simple way? We'll have to put these > > > > under machine type. > > > > > > I agree. Hyper-V is not just a set of CPU features. > > me too, > > however in this case we are talking about a set of cpu features, > > if there is no way to implement it as cpu properties + compat properties > > and requires opencodding it within machine code it might be fine > > but I fail to see a very good reason for doing that at this momment. > > The reason would be just simplicity of implementation. aside other issues, cpu props + compact_props looks simpler than machine based variant. > > I understand there are reasons to suggest using compat_props if > it makes things simpler, but I don't see why we would reject a > patch because the implementation is not based purely on > compat_props. main issue is that patch introduces new semantics to cpu feature parsing. compat_props is for consistency with how we typically handle device compatibility, which is also good enough reason. > I will let Vitaly to decide how to proceed, based on our > feedback. I encourage him to use compat_props like you suggest, > but I don't plan to make this a requirement. > > > > > > > > > Also, those two approaches are not mutually exclusive. > > > "-machine hyperv=on" can be implemented internally using > > > "hyperv-use-preset=on" if necessary. I don't think it has to, > > > however. > > > > >