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 5460DC4332F for ; Wed, 13 Dec 2023 20:25:35 +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:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=5Nc+W2VIE/lLMDcBfnmyZHSeFmUqPeseyNw4IoPZywo=; b=olzkAaFkMfhpVL r/dfz8zHi3USGWS08nJ3UJ60kUFqWWXiDiUwqsyGRbLPJWvszaGnyxt8zqznf7KHaKudsVtv8MgQ8 HW7QvmpDJK7ux9yzgD0bL1GE+7HCozwvFwEL5clWs5vx8qfl3Dnd25tk805t7V/b8UE+gTvetgpP+ Rfl4plmt5fFRcJCOQ/tan/iBmqxm7BO30v3JbTiK8W0x6j++8RlbrHVzC+nBchglXXM8cXgAcw4H/ LsLItgnzlSyfTfSS/cOI5ag+kBUR6ipNzbL1tg3p1pvh2Hk7HBeT7pyvYStqQEUzDDHs9YjxmHO7+ scAaVtbPeJu9vWhLe02Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1rDVn5-00Fxes-0e; Wed, 13 Dec 2023 20:25:11 +0000 Received: from out-173.mta1.migadu.com ([2001:41d0:203:375::ad]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1rDVn2-00FxeD-0S for linux-arm-kernel@lists.infradead.org; Wed, 13 Dec 2023 20:25:10 +0000 Date: Wed, 13 Dec 2023 20:24:59 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1702499103; 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=tNO556z6FFu06V81OQ+zyHsSpgoOG3daD8uh3SUI1ew=; b=T6LceOf1lh7wrllqQaFpMBvKcbmWs5Pk1nsncOiFxJKxrkHkBzMfunILFugu3pMqCSi4l1 JxX1ftanMmMjMTsZ0G/v3WfDCy51zMJ78l7UAA9EsRVeCzyoMxsfin/ewGmRjUtgwUpLaX 59UfWFQsum6fJnvdJllp7g0LlINclcA= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Oliver Upton To: James Morse Cc: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, Marc Zyngier , Suzuki K Poulose , Zenghui Yu Subject: Re: [PATCH v2 0/4] KVM: arm64: Hide unsupported MPAM from the guest Message-ID: References: <20231207150804.3425468-1-james.morse@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20231207150804.3425468-1-james.morse@arm.com> X-Migadu-Flow: FLOW_OUT X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20231213_122508_594981_86E8FF45 X-CRM114-Status: GOOD ( 18.94 ) 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 Hi James, Thank you very much for posting these fixes. On Thu, Dec 07, 2023 at 03:08:00PM +0000, James Morse wrote: > 'lo > > This series fixes up a long standing bug where MPAM was accidentally exposed > to a guest, but the feature was not otherwise trapped or context switched. > This could result in KVM warning about unexpected traps, and injecting an > undef into the guest contradicting the ID registers. > This would prevent an MPAM aware kernel from booting - fortunately, there > aren't any of those. > > Ideally, we'd take the MPAM feature away from the ID registers, but that > would leave existing guests unable to migrate to a newer kernel. Instead, > use the writable ID registers to allow MPAM to be re-enabled - but emulate > it as RAZ/WI for the system registers that are trapped. This is certainly a reasonable approach, but TBH I'm not too terribly concerned about the completeness of the workaround plumbing that we need here. Undoubtedly what you propose is the most complete solution to the problem, but it is somewhat involved. So long as we don't break migration at the userspace ioctl level I'm not too worried. Maybe something like: - Ensure the reset value of ID_AA64PFR0_EL1.MPAM is 0 - Allow userspace to write ID_AA64PFR0_EL1.MPAM as 1, *but* - KVM reinterprets this as '0' behind the scenes for the final register value - Add the MPAM registers to the sysreg table with trap_raz_wi() as the handler to avoid the unsupported sysreg printk, since it is possible that older VMs may've already seen the MPAM feature. We've already done something similar to hide our mistakes with IMP DEF PMU versions in commit f90f9360c3d7 ("KVM: arm64: Rewrite IMPDEF PMU version as NI"), and I think MPAM may be a good candidate for something similar. -- Thanks, Oliver _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel