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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 38414C77B7A for ; Tue, 16 May 2023 14:19:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:Message-ID:Date:References :In-Reply-To:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=gIYIeSes+4HksA75I+69mWe4IPghW8d8xPDXxz0u9sA=; b=NUlodNenx92jF0 FcCWHcUvTzQjYldTWDvcPn7Lnk+0lddpZrzSrHN60djWBPOO8SoDcj+QwH20W4BE/irAACnxt5a3U hliX41mXZe83Wk8keF/4kLUfLPxdBzMhr+GxNtVuBZ7Vu2mIeLE6NUVy3PincYnSCgf9jhq8kf/dy VUJ8VEj+5NEoXfoif29P+vS+wIWG+fDbIbLLtyMUXWKK3D5kN0O7kcT5rLTq2vkLehPX08eWVdRDt H/3Lo3Xll0T4fA5V+htBHgaMfI8MBgltwUc41Zl6g2vdDRMjRjaGjvDZyoAtxCSBjry8LGVMXMBC5 ZDJQRgqOiFQvjU1kx4VQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1pyvWB-0063f2-21; Tue, 16 May 2023 14:19:11 +0000 Received: from us-smtp-delivery-124.mimecast.com ([170.10.129.124]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1pyvW8-0063ch-0D for linux-arm-kernel@lists.infradead.org; Tue, 16 May 2023 14:19:10 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1684246745; 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=FXV8+kPpgJVEuMcxQ38ltGoZl/HtyeVRK1HJvm3lGSw=; b=VTea9aubDL/dD/wihuvr3J6sXRa6KfHZScq3Z1ioupOM7+0Z/wYzkeczqDVC6Pb0KsS6ze sO5f6EG1ChxsIn+fNQLXIQFk8eF5rNI3+Bd3BUSqFC3B2Zt/sOWmz3VxqG2uDA3He9lFP3 MeL2EFVxQ2utHy6ZZXYfhErO25zF5DE= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-581-g-sG8WJmNZ67hxwXZGELBA-1; Tue, 16 May 2023 10:19:03 -0400 X-MC-Unique: g-sG8WJmNZ67hxwXZGELBA-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id D692F857DE4; Tue, 16 May 2023 14:19:01 +0000 (UTC) Received: from localhost (dhcp-192-239.str.redhat.com [10.33.192.239]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 94BCA63ABB; Tue, 16 May 2023 14:19:01 +0000 (UTC) From: Cornelia Huck To: Marc Zyngier Cc: Shameerali Kolothum Thodi , Jing Zhang , KVM , KVMARM , ARMLinux , Oliver Upton , Will Deacon , Paolo Bonzini , James Morse , Alexandru Elisei , Suzuki K Poulose , Fuad Tabba , Reiji Watanabe , Raghavendra Rao Ananta Subject: Re: [PATCH v8 0/6] Support writable CPU ID registers from userspace In-Reply-To: <867ct8mnel.wl-maz@kernel.org> Organization: Red Hat GmbH References: <20230503171618.2020461-1-jingzhangos@google.com> <2ef9208dabe44f5db445a1061a0d5918@huawei.com> <868rdomtfo.wl-maz@kernel.org> <1a96a72e87684e2fb3f8c77e32516d04@huawei.com> <87cz30h4nx.fsf@redhat.com> <867ct8mnel.wl-maz@kernel.org> User-Agent: Notmuch/0.37 (https://notmuchmail.org) Date: Tue, 16 May 2023 16:19:00 +0200 Message-ID: <87a5y4gy0b.fsf@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.5 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230516_071908_205834_9247ED37 X-CRM114-Status: GOOD ( 25.44 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, May 16 2023, Marc Zyngier wrote: > On Tue, 16 May 2023 12:55:14 +0100, > Cornelia Huck wrote: >> >> Do you have more concrete ideas for QEMU CPU models already? Asking >> because I wanted to talk about this at KVM Forum, so collecting what >> others would like to do seems like a good idea :) > > I'm not being asked, but I'll share my thoughts anyway! ;-) > > I don't think CPU models are necessarily the most important thing. > Specially when you look at the diversity of the ecosystem (and even > the same CPU can be configured in different ways at integration > time). Case in point, Neoverse N1 which can have its I/D caches made > coherent or not. And the guest really wants to know which one it is > (you can only lie in one direction). > > But being able to control the feature set exposed to the guest from > userspace is a huge benefit in terms of migration. Certainly; the important part is that we can keep the guest ABI stable... which parts match to a "CPU model" in the way other architectures use it is an interesting question. It almost certainly will look different from e.g. s390, where we only have to deal with a single manufacturer. I'm wondering whether we'll end up building frankenmonster CPUs. Another interesting aspect is how KVM ends up influencing what the guest sees on the CPU level, as in the case where we migrate across matching CPUs, but with a different software level. I think we want userspace to control that to some extent, but I'm not sure if this fully matches the CPU model context. > > Now, this is only half of the problem (and we're back to the CPU > model): most of these CPUs have various degrees of brokenness. Most of > the workarounds have to be implemented by the guest, and are keyed on > the MIDR values. So somehow, you need to be able to expose *all* the > possible MIDR values that a guest can observe in its lifetime. Fun is to be had... > > I have a vague prototype for that that I'd need to dust off and > finish, because that's also needed for this very silly construct > called big-little... That would be cool to see. Or at least interesting ;) _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel