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 0B381D2C54A for ; Tue, 22 Oct 2024 12:54:14 +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:Content-Type:MIME-Version: References:In-Reply-To:Subject:Cc:To:From:Message-ID: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=OtSiFiFdDCKhE+9iBBXrkeGyTdhvSON3OA5M6Nq/UMI=; b=X7AhzvT0+HpM0ebUWkxSc7VliZ FQH9wah8PbPn9fd3qSfORp1y3NFPT2gtcFuyaB/AsN5X9Qkp564R1hs47d9dMs1uWS6zLbJt4lw8F S5Uyp9wCttCVxlzFJ6nTbd+LBZUx+DtSoetDdSLgk3yzMeeHd9c85EMCROO5yxjHmgUdlEe2glhfq NAoqLDQOpY736D5rHr/ntn5uOucwmgscZf8p26TFtj+3e0v9M9BM0HFuwEDQ5iG+jQ7SbIlr+3zY/ iSyCS6qEvUrEQYcGg7bGt0MU+EK0dFchk9W2t/t3LaPATDe/JdkLReqyo3T271fvsNP608uKmtqoo 3VLFwbDQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1t3EOg-0000000AsU0-0aNm; Tue, 22 Oct 2024 12:54:02 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1t3EMr-0000000AsGH-0Vrl for linux-arm-kernel@lists.infradead.org; Tue, 22 Oct 2024 12:52:10 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 7DA545C543F; Tue, 22 Oct 2024 12:52:03 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B478BC4CEC3; Tue, 22 Oct 2024 12:52:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1729601527; bh=SrytKomT5rTn2vdNWx7adZOSug/HjdryTVVh7dbDC5w=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=fyfUpjyyF6S++IvObvuTiKagThQppvB6/9fPT8Wqhksfc7C9zUsrDDz/CvsQkhIbY luGl2PPROZYXUxCizKX1mYdqGqt2pYytbbWLfP+1/PhaSxiI2tYnT5/QkTO5XktBQt gSZU2uJi//DCCESQ0uTnUImYPPQxIMINhlTxrfUvfJU4xIkh2rZHdEMhMgGoxc+9ym HqRstqZRH3GNQZeFqGeTXFNHHjSC5OA6WA1yldRo8zf7mX29sflAkqtj2D/OyxdFMz HemNcrRSWFoDe/sVOhB2JhLh6vOVAJtMdr3TnTjh+0TWYY1QbJQbZyedkVTNAIr9Si QwL1m8D2Az12w== 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 1t3EMn-005mJC-8A; Tue, 22 Oct 2024 13:52:05 +0100 Date: Tue, 22 Oct 2024 13:52:04 +0100 Message-ID: <86bjzc47wr.wl-maz@kernel.org> From: Marc Zyngier To: Cornelia Huck Cc: Oliver Upton , eric.auger@redhat.com, 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 In-Reply-To: <87o73cpfph.fsf@redhat.com> 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> <87o73cpfph.fsf@redhat.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/29.4 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: cohuck@redhat.com, oliver.upton@linux.dev, eric.auger@redhat.com, shameerali.kolothum.thodi@huawei.com, kvmarm@lists.linux.dev, catalin.marinas@arm.com, will@kernel.org, mark.rutland@arm.com, yuzenghui@huawei.com, wangzhou1@hisilicon.com, jiangkunkun@huawei.com, jonathan.cameron@huawei.com, anthony.jebson@huawei.com, linux-arm-kernel@lists.infradead.org, linuxarm@huawei.com 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-20241022_055209_274578_8B7CBF44 X-CRM114-Status: GOOD ( 38.70 ) 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 Tue, 22 Oct 2024 11:58:02 +0100, Cornelia Huck wrote: > > On Fri, Oct 18 2024, Oliver Upton wrote: > > > 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. > > So basically, the VMM would have to make a choice which guests it wants > to support? Modern guests, which are aware through the hypercall > interface what is going on and are able to parse any information in our > synthetic MIDR correctly, or older guests, which should be presented > with a MIDR that makes them hopefully act in the way we want it to act? > > I guess that would mean that for full migration support between > different hosts, we'd want enlightned guests, and for (some) other > cases, we could generate a configuration that will hopefully work? That's sums it up, I think. The way I think of it is that, at VM creation, you decide what you want to support: - homogeneous migration: that's basically what we have today, with some limited flexibility. - heterogeneous migration: synthetic MIDR, discovery hypercall, the works. > (Spoofing for testing things sounds useful regardless.) My problem with that is that there is no difference in ABI between "I want this for testing" and "I expect this to fully work". The latter is obviously not achievable... Thanks, M. -- Without deviation from the norm, progress is not possible.