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 EB701C43217 for ; Thu, 1 Dec 2022 11:08:39 +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:References:In-Reply-To: Subject:Cc:To:From:Message-ID:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=7ND2zuQjkTWHBfq+/chS4PHK0jXtJO3Rgvgg15/y6Dg=; b=3cnnYMuKgBSuam e0SrNlCHydSxV/J4Df89PZmTWqsxjidw/3UmdmB/lkc3WP9LrdB56CclR7d0owCzTK01kvFQ+EnIE BHVKDBuw1qY54zIKbF4PRT8hlQYRL2nEBphn8vtg8SwZY7t9JH4CLvtQ7exZ3zhqY5bmzAYtN9Rg1 Z6dVZKxjwj2uDpS1iqVA9Yy0YQGQXcQYiRNCGBZdh2gz8A5ICfdJD2uyDz2w43NFdG2mac8QbHF+P Er3HRfVlyA14yWGEfoCzphOSo03pBuW/73eDU8GaB+IUlAPiv/hHnJk4TIL4H+vK4xones+RdDHnh UXdiKomaN9qLq/l8X+ZA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1p0hPc-006wL1-LS; Thu, 01 Dec 2022 11:07:30 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1p0hP5-006w2L-G6 for linux-arm-kernel@lists.infradead.org; Thu, 01 Dec 2022 11:06:57 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 0991C61F8B; Thu, 1 Dec 2022 11:06:55 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 68650C433D6; Thu, 1 Dec 2022 11:06:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1669892814; bh=i2np9F56qLywDr0RX1dy9AOjTdnmeeEccNFFBfjcT8U=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=XjPGLWxmn9oQO4FFerUe64zD1DnnuQMWv5kw6ej4pQ+vum0dRpQfw5DIg/F5OmR98 M7B41ZUi93fNrJav4R2Vl+UtOfStKc/6AB89nUSjMXvaEt7Zv+qopXqYoQ+Z4B2RTr /yZiyEe+yCwd6i+6UOu6IEVb6iQzATF+tgN+mdIDFKhL+Hg113FREev30545rFbmw9 m8KlzYl5C/xNvwp1q9iL+WLFoqYt8wq6tjVLJ07UxZT4RFmZX5Q9jDxMRGk8PG6DnQ HDQE2C8VykJ7Q09bMsD/pLqfV8Q5kMyDe9qDdy2Gz8VdJ6HE4lB6Oyd7yWwN7SZykX YszOhHrZDq1+w== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1p0hP0-009oHg-Qi; Thu, 01 Dec 2022 11:06:52 +0000 Date: Thu, 01 Dec 2022 11:06:50 +0000 Message-ID: <867czbmlh1.wl-maz@kernel.org> From: Marc Zyngier To: Akihiko Odaki Cc: linux-kernel@vger.kernel.org, kvmarm@lists.linux.dev, kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org, Mathieu Poirier , Oliver Upton , Suzuki K Poulose , Alexandru Elisei , James Morse , Will Deacon , Catalin Marinas , asahi@lists.linux.dev, Alyssa Rosenzweig , Sven Peter , Hector Martin Subject: Re: [PATCH 0/3] KVM: arm64: Handle CCSIDR associativity mismatches In-Reply-To: <20221201104914.28944-1-akihiko.odaki@daynix.com> References: <20221201104914.28944-1-akihiko.odaki@daynix.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: akihiko.odaki@daynix.com, linux-kernel@vger.kernel.org, kvmarm@lists.linux.dev, kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org, mathieu.poirier@linaro.org, oliver.upton@linux.dev, suzuki.poulose@arm.com, alexandru.elisei@arm.com, james.morse@arm.com, will@kernel.org, catalin.marinas@arm.com, asahi@lists.linux.dev, alyssa@rosenzweig.io, sven@svenpeter.dev, marcan@marcan.st X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221201_030655_641864_FDD143D6 X-CRM114-Status: GOOD ( 18.89 ) 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 Thu, 01 Dec 2022 10:49:11 +0000, Akihiko Odaki wrote: Thanks for looking into this. > M2 MacBook Air has mismatched CCSIDR associativity bits, which makes the > bits a KVM vCPU sees inconsistent when migrating. Can you describe the actual discrepancy? Is that an issue between the two core types? In which case, nothing says that these two cluster should have the same cache topology. > It also makes QEMU fail restoring the vCPU registers because QEMU saves > and restores all of the registers including CCSIDRs, and if the vCPU > migrated among physical CPUs between saving and restoring, it tries to > restore CCSIDR values that mismatch with the current physical CPU, which > causes EFAULT. Well, QEMU will have plenty of other problems, starting with MIDRs, which always reflect the physical one. In general, KVM isn't well geared for VMs spanning multiple CPU types. It is improving, but there is a long way to go. > Trap CCSIDRs if there are CCSIDR value msimatches, and override the > associativity bits when handling the trap. TBH, I'd rather we stop reporting this stuff altogether. There is nothing a correctly written arm64 guest should do with any of this (this is only useful for set/way CMOs, which non-secure SW should never issue). It would be a lot better to expose a virtual topology (one set, one way, one level). It would also save us from the CCSIDRX silliness. The only complexity would be to still accept different topologies from userspace so that we can restore a VM saved before this virtual topology. Do you mind having a look at this? Thanks, M. -- Without deviation from the norm, progress is not possible. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel