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 B5DE2C04FFE for ; Wed, 8 May 2024 12:08:38 +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=RQkRIUILxjfeexZ/nJe+6loVvLIWIXykpC8t1YYKhMo=; b=exrz4vuJtqHNVK CFEw02qE3UcyBJMM2rJ1HNLNLLqXWCaZJv6jMmTJaGBPN3AueWV9VrXoRNmZR7utBHorLDPhV484t aen5J8seaoA8h9TPxgOPLEkyhVaCm+Jt97paX8lnP1mxmnHtxz8NGuiesdnW/eBUs//F9IBDgME/4 LLqWmpNcE31i+mwlwySMKNl397Y199lkxI18t+Gcf8LzMn6udZA/R0DRboW+sAoC2tWGjP0QPhZU0 zgt6tfp/8SdnxbMyNFnx59K2a9CaYTmWCLV1Tt+6cfJAIpyOVjH0L+dEByBpVqwA7jW2JKnOvORbY SCl+qFWBFYn19wqCryKA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1s4g5v-0000000FOA5-1fzI; Wed, 08 May 2024 12:08:23 +0000 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1s4g5s-0000000FO8w-1nHB for linux-arm-kernel@lists.infradead.org; Wed, 08 May 2024 12:08:22 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1715170098; 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=kch4CR6jb0EO3CtRVrd4DZN/+JzXwlHyRHSCeA2eEfY=; b=NWVZadvvxZdeM5K4V3tajlBNW+B7cqhaoZTD4mZNfSOjnXK9SECXj9FV8RGLyOyeRVaEGn 1Ft4L1k8HZuklQfJHKjpzmYjWMOoSEa0+0CbQ4GTTYGIh3esNZRktr6MfhEKUTLA8f7TgJ VDUz+JxreLmUe414jRUTN0+cIiEPN4k= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-624-x3CuWCx9O8KAM64vBGyp9A-1; Wed, 08 May 2024 08:06:39 -0400 X-MC-Unique: x3CuWCx9O8KAM64vBGyp9A-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 7C5BF80021D; Wed, 8 May 2024 12:06:38 +0000 (UTC) Received: from localhost (dhcp-192-239.str.redhat.com [10.33.192.239]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C9B787414; Wed, 8 May 2024 12:06:37 +0000 (UTC) From: Cornelia Huck To: Oliver Upton , "Russell King (Oracle)" 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 In-Reply-To: Organization: "Red Hat GmbH, Sitz: Werner-von-Siemens-Ring 12, D-85630 Grasbrunn, Handelsregister: Amtsgericht =?utf-8?Q?M=C3=BCnchen=2C?= HRB 153243, =?utf-8?Q?Gesch=C3=A4ftsf=C3=BChrer=3A?= Ryan Barnhart, Charles Cachera, Michael O'Neill, Amy Ross" References: User-Agent: Notmuch/0.38.3 (https://notmuchmail.org) Date: Wed, 08 May 2024 14:06:36 +0200 Message-ID: <87jzk4h5ir.fsf@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.5 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240508_050820_952962_13603859 X-CRM114-Status: GOOD ( 35.67 ) 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, May 02 2024, Oliver Upton wrote: > On Thu, May 02, 2024 at 03:40:38PM +0100, Russell King (Oracle) wrote: >> 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. > > Yeah, so this is something that has affected my employer as well. > > I think (1) should only be expected of VMMs that want rollback safety, > i.e. the ability to migrate state back to an older kernel. Our userspace > initializes vCPUs from a fixed set of feature ID register values that > prevents VMs on new kernels from picking up new CPU features. > > It is quite tedious, but necessary as rollback safety is very much a > non-goal of the KVM UAPI. Depending on your use case, rollback safety might be quite important... have we ever stated exactly which guarantees the KVM UAPI is giving? IOW, can someone implementing a VMM look at a doc and see "oh, if I want to be able to go backwards, I need to be able to deal with x, y, and z coming up on the new kernel"? > > OTOH, in cases where KVM screws up and breaks UAPI, the kernel needs to > do something special to accept the previously-advertised state even if > it were nonsensical. > > For example, there was a bug where KVM advertised an IMP DEF PMU to VMs > even though the only thing KVM virtualizes is PMUv3. We fixed it in > commit f90f9360c3d7 ("KVM: arm64: Rewrite IMPDEF PMU version as NI") by > accepting the old value in the ioctl and changing the field to NI > internally. > > I dislike these sort of hacks, but when we're caught between upholding > UAPI and the architecture it seems to be the best option. I wonder if an > approach similar to this would be sufficient to address the SPE change > that you noticed. > >> 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. > > This is intended behavior, as VMs are initialized to the maximum feature > set KVM is able to support. Forward-compatibility for the set of exposed > registers is tested, see the get-reg-list selftest. I've seen this problem come up as well; if it is clear that this is something that KVM expects the VMM to handle if needed, that is fine; should we consider "it's tested in a selftest" as a canonical indicator of "this is what KVM supports compatibility wise"? _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel