From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pandora.armlinux.org.uk (pandora.armlinux.org.uk [78.32.30.218]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3CFE9152E12 for ; Thu, 2 May 2024 14:40:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=78.32.30.218 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1714660860; cv=none; b=H6V9rf+jN/7R8YrLTeblqgMhqiinj/iRhwKZPiBbsF7M0h4Qd6qVPF0fET24ILoMr6sm8aL2Tbra0n3qb6/v4K2yI2EE7/Z3dI+N0+erjaLYYzIT5WEEwPP+DEZW99vuxIZ5Sxh9nu+f7QphtBL05iSsxZBysZy3WKn6NdEhrtw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1714660860; c=relaxed/simple; bh=W7cYrxz5C/2O+2De37Gc0G200thQE/MIJBh0CXKi4ZA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=KTtD7MFPwJ+3F8rdEd7FMv7NcOPoTN00O2csuj7vBv991DRbAPW4N0AWsevvoeka4ib8UBUQNwa1Thy8pu/jRPdXtwqGPZHKC2Fe+wSUZPx6w6yfFKan9TxtRwVZEB5Gjvbfk2+Zm7XJxcnnani3tEvE8mVhdvTKYYjgvRffV4Y= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=armlinux.org.uk; spf=none smtp.mailfrom=armlinux.org.uk; dkim=pass (2048-bit key) header.d=armlinux.org.uk header.i=@armlinux.org.uk header.b=R/PA3Wk5; arc=none smtp.client-ip=78.32.30.218 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=armlinux.org.uk Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=armlinux.org.uk Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=armlinux.org.uk header.i=@armlinux.org.uk header.b="R/PA3Wk5" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=PNPomXF+88NXnOR05FF/hWkfp3ALBA3dcNLoX3C+ZiI=; b=R/PA3Wk5tRgnvnb8thgVz8xSI7 L3uurutXSsAt74hyChUoXy9eKjPOf2pzSAILff4hRBQw1enUY3id4OScWEj3aYGcyEvGHMPOXOLqh rZJrvHFVjHtRPcRo3sSo0DxBJjqTuauj0TM7VshnRSnFKju+iKiBoly7MV4nnJJAEx4GZrT12n60J h9aOC5SNEcciXJwVkE38uCOqImYUXNIhGV4U+5jAKDXds6yXbXRUPwQ78HR9T89CAN2GJBLL2/HUu N+peIhRNnet8Y6DOXySaT8V5cfgPaa6H7vdsNzO+D6mdPdL3clEg/oU03JbczVcbqanxcDyduOJqJ frVcZTHA==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:48122) by pandora.armlinux.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1s2Xc0-0007O8-1D; Thu, 02 May 2024 15:40:40 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.94.2) (envelope-from ) id 1s2Xby-0003j5-BY; Thu, 02 May 2024 15:40:38 +0100 Date: Thu, 2 May 2024 15:40:38 +0100 From: "Russell King (Oracle)" To: Oliver Upton Cc: Marc Zyngier , Catalin Marinas , Will Deacon , James Morse , Suzuki K Poulose , Zenghui Yu , linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev Subject: Re: [PATCH RFC] KVM: arm64: allow ID_MMFR4_EL1 to be writable Message-ID: References: Precedence: bulk X-Mailing-List: kvmarm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: Russell King (Oracle) On Wed, May 01, 2024 at 06:59:17PM +0000, Oliver Upton wrote: > On Wed, May 01, 2024 at 07:08:05PM +0100, Russell King (Oracle) wrote: > > Yes, it did strike me as odd, since the description seems to imply that > > XNX affects EL2, which the VM wouldn't have access to. So I'm not sure > > why we don't just force it to zero. > > Probably because we failed to catch it in the first place and setting to > 0 now would be even more UAPI breakage. Meh :-/ I don't see any immediate > issues with the patch, especially since it is fixing a genuine UAPI > breakage in KVM. I think the only two ways around this would be to: 1) teach QEMU about the contents of these registers, with which fields in these registers can be ignored when reloading a VMs context. 2) allow userspace to write to the XNX field such that it can be set to values seen with previous kernels (thus allowing at least one- way migration.) (1) has the advantage that reloading a VM state on older vs newer kernels can work in either direction, whereas (2) would only work for state saved on an older kernel loaded onto a newer kernel. I've been bitten before with KVM differences between kernel versions in the past - where the number of registers that userspace sees has changed despite being on the same hardware. I'm now wondering what testing goes on to validate this part of the UAPI across different kernel versions on the same hardware. Surely, given the impact of these changing value (a failure of VMs), we should be aware whenever any of these registers are different from one kernel to another on the same hardware? It's fine if all one cares about is starting fresh VMs on each host kernel reboot, but any use case beyond that seems to be fragile. I did knock up a test program that dumped the list of registers so that one could trivially diff the output between various kernels. Maybe I need to extend that to dump the register values themselves, and then maybe we need to find a way to get some kind of automated testing setup to highlight differences. (something maybe kernelci could add?) -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last! 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 07D6BC4345F for ; Thu, 2 May 2024 14:41:07 +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=BRtrN5C8RpCKx1LwpvZosGyMgOpGZf+VnyQZ+1WLHew=; b=cd9oNrhv6MyKUr yoHHnamlppm/oJ0QiNZOJ2/YJzvMWk0hpQjfXSImQahahfSGisNpLuxIpJ/UuhS1BJYxrHEk2ZFX1 YmFhhK8z77whlJDY19iBbc2rNTWoWuCsruMb3tIhhH8nakGBr04zPd5SZ9pUH727XlkdC8NUBo9Gy XpHeSSCZAIoZ1f4xSMMIbtGWMVqNv+osCC6euQJL+DKFotq2xv4mozZUjhwJwKI8L1vfPpO0Pxoi7 akuL7Etcc8bpHqbGQUTz/djQ2NcSUe5nzwWxza00JCmIThccRkobA7qwSn9kih2DtGEeFqtHXtipi VV+kdmcjnyjHbXHziepA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1s2XcF-0000000CxZr-32Ix; Thu, 02 May 2024 14:40:55 +0000 Received: from pandora.armlinux.org.uk ([2001:4d48:ad52:32c8:5054:ff:fe00:142]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1s2XcC-0000000CxYp-394i for linux-arm-kernel@lists.infradead.org; Thu, 02 May 2024 14:40:54 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=PNPomXF+88NXnOR05FF/hWkfp3ALBA3dcNLoX3C+ZiI=; b=R/PA3Wk5tRgnvnb8thgVz8xSI7 L3uurutXSsAt74hyChUoXy9eKjPOf2pzSAILff4hRBQw1enUY3id4OScWEj3aYGcyEvGHMPOXOLqh rZJrvHFVjHtRPcRo3sSo0DxBJjqTuauj0TM7VshnRSnFKju+iKiBoly7MV4nnJJAEx4GZrT12n60J h9aOC5SNEcciXJwVkE38uCOqImYUXNIhGV4U+5jAKDXds6yXbXRUPwQ78HR9T89CAN2GJBLL2/HUu N+peIhRNnet8Y6DOXySaT8V5cfgPaa6H7vdsNzO+D6mdPdL3clEg/oU03JbczVcbqanxcDyduOJqJ frVcZTHA==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:48122) by pandora.armlinux.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1s2Xc0-0007O8-1D; Thu, 02 May 2024 15:40:40 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.94.2) (envelope-from ) id 1s2Xby-0003j5-BY; Thu, 02 May 2024 15:40:38 +0100 Date: Thu, 2 May 2024 15:40:38 +0100 From: "Russell King (Oracle)" To: Oliver Upton Cc: Marc Zyngier , Catalin Marinas , Will Deacon , James Morse , Suzuki K Poulose , Zenghui Yu , linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev Subject: Re: [PATCH RFC] KVM: arm64: allow ID_MMFR4_EL1 to be writable Message-ID: References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240502_074052_999931_97BB582A X-CRM114-Status: GOOD ( 22.38 ) 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 Wed, May 01, 2024 at 06:59:17PM +0000, Oliver Upton wrote: > On Wed, May 01, 2024 at 07:08:05PM +0100, Russell King (Oracle) wrote: > > Yes, it did strike me as odd, since the description seems to imply that > > XNX affects EL2, which the VM wouldn't have access to. So I'm not sure > > why we don't just force it to zero. > > Probably because we failed to catch it in the first place and setting to > 0 now would be even more UAPI breakage. Meh :-/ I don't see any immediate > issues with the patch, especially since it is fixing a genuine UAPI > breakage in KVM. I think the only two ways around this would be to: 1) teach QEMU about the contents of these registers, with which fields in these registers can be ignored when reloading a VMs context. 2) allow userspace to write to the XNX field such that it can be set to values seen with previous kernels (thus allowing at least one- way migration.) (1) has the advantage that reloading a VM state on older vs newer kernels can work in either direction, whereas (2) would only work for state saved on an older kernel loaded onto a newer kernel. I've been bitten before with KVM differences between kernel versions in the past - where the number of registers that userspace sees has changed despite being on the same hardware. I'm now wondering what testing goes on to validate this part of the UAPI across different kernel versions on the same hardware. Surely, given the impact of these changing value (a failure of VMs), we should be aware whenever any of these registers are different from one kernel to another on the same hardware? It's fine if all one cares about is starting fresh VMs on each host kernel reboot, but any use case beyond that seems to be fragile. I did knock up a test program that dumped the list of registers so that one could trivially diff the output between various kernels. Maybe I need to extend that to dump the register values themselves, and then maybe we need to find a way to get some kind of automated testing setup to highlight differences. (something maybe kernelci could add?) -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel