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 22355D3DEAB for ; Fri, 18 Oct 2024 18:56:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id: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-Owner; bh=N7gGee0VoX3/3pvOl5YQTwO9KIrTBzmVncNX5uAOKK0=; b=FWLo1cxdj/2z0dD3jPBKghyiQS 1ND0qY5Ll34yoGEtjVnUSIYiTKrPG+iBk1lkUXbu33V0mos6uHwfV42MExtLhdtecsMzl85VBsXQV gD6jefAGEz/IlFGxahUntgPi/XdMcORDavnVYasPWe7co2rEXNY74jzmPBH+iT1KdKxMeHoewJ/Vz y39F0717QCll8d8bbh1cUYRA9/MD68LefR4GzFr3nkqOoc13KruK2i9XVrotIuAKsVknHpNE/PIMQ fs8OdLsNMOz36jSVXA9hGOa/7IP9qHrAaysSVAoiSyeLeo09wnXKxqUO1zAru0vQajAhTN7ZqA0dG QvKGys/w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1t1s8f-00000001iFs-1fql; Fri, 18 Oct 2024 18:55:53 +0000 Received: from out-184.mta0.migadu.com ([2001:41d0:1004:224b::b8]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1t1s5k-00000001hqg-3vat for linux-arm-kernel@lists.infradead.org; Fri, 18 Oct 2024 18:52:54 +0000 Date: Fri, 18 Oct 2024 11:52:37 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1729277564; 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=N7gGee0VoX3/3pvOl5YQTwO9KIrTBzmVncNX5uAOKK0=; b=ls1aEg3mc1hFdNhE7b/nh+s9QFEDJy4/74kbOZG0dZJ56Ynjs8L1KtVT/eGx1MINgZA4je 6f4gU1PLfAcf299w6NyuR+V9uLWCBKfk6N/Vx5RNyr4hUI+UmqXLt9XQtpXq5EvTuqzZ7D POGiWC3oj2KHu4IBs8OoasQ2u56P+CY= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Oliver Upton To: Marc Zyngier Cc: eric.auger@redhat.com, Cornelia Huck , Shameerali Kolothum Thodi , "kvmarm@lists.linux.dev" , "catalin.marinas@arm.com" , "will@kernel.org" , "mark.rutland@arm.com" , yuzenghui , "Wangzhou (B)" , jiangkunkun , Jonathan Cameron , Anthony Jebson , "linux-arm-kernel@lists.infradead.org" , Linuxarm Subject: Re: [RFC PATCH 0/6] KVM: arm64: Errata management for VM Live migration Message-ID: References: <20241011075053.80540-1-shameerali.kolothum.thodi@huawei.com> <86jzef53iz.wl-maz@kernel.org> <3f4469c49625413f9ab2c224d0d3fbea@huawei.com> <86ikty6f1b.wl-maz@kernel.org> <08261a41b9644f5ab49063824e4060c3@huawei.com> <87bjziraou.fsf@redhat.com> <7df21c56-0b07-4112-839e-ef90c5999fcd@redhat.com> <86frot4kki.wl-maz@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86frot4kki.wl-maz@kernel.org> X-Migadu-Flow: FLOW_OUT X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20241018_115253_149426_8C28D13F X-CRM114-Status: GOOD ( 22.91 ) 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Oct 18, 2024 at 02:17:17PM +0100, Marc Zyngier wrote: > On Thu, 17 Oct 2024 18:16:04 +0100, > Eric Auger wrote: > > > > Hi Shameer, > > > > On 10/17/24 17:49, Cornelia Huck wrote: > > > > Speaking of QEMU: Do you maybe already have some prototype code that > > > tries to do something with the setup here? (I don't think QEMU currently > > > mucks around with MIDR and friends when running with KVM; I wonder what > > > it should provide to the guest and if it should care to set something as > > > a base level that gives guests not using the hypercall a chance to work > > > properly.) > > > > > As discussed during the KVM forum we are working on a qemu integration > > for writable ID regs. The first goal is to be able to specialize the > > host passthrough model (custom host model). Maybe this will trigger more > > discussions on named models too. This is complementary to the > > MIDR/REVIDR problematic and I hope we will be able to consolidate our > > works at some point. > > Complementary to the MIDR/REVIDR work, I would also like to make > MIDR/REVIDR writable when this scheme is available. Ideally reporting > a synthetic CPU description (with MIDR_EL1.Implementer returning 0, > and the rest being VMM-specific, but with a clear definition for the > IMPDEF fields so that we can version the ABI). When the VMM is using the hypercall mechanism to describe implementations, 100% agree. > Thoughts? I think we should go a step further and allow userspace full control of known fields in these registers, even for a nonzero Implementer code. We're already affording userspace full control of what implementation(s) the guest sees anyway via hypercalls, so there isn't much left for KVM to enforce. Ignoring errata, it'd let folks spoof an old implementation on newer hardware for testing, especially when dealing w/ older software. -- Thanks, Oliver