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 68C82D24470 for ; Fri, 11 Oct 2024 17:09:19 +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=B7SnnnTfOwt4kWHiPAWUzLS15XAxy5TfsaE83NvMhaE=; b=B/AsWoolelin2Zx5L+yEurfbDj fv//OdO5ImT3v8lmM1Fj63fJ9nT0AHpG9QaLZVZZ/3HrpgJ32rpTA1oebD8IS4bFCRJYaaQHA32cq ZeLPztk58MD1977RUoUuICh6VU5m4X9X4fUByfILbvrCat7L1ZB3B9KsGsdwC2gg3EjwX7eIj8P/x FD+GNACbiOLvyyH4zuOifVfHZCb7OcC3qrsTkDKxbncyDuZSNUjhQjA7SBI4Bh1uHk5oxLpMzL+7O d8vWe8xnIsj3joQJhE/fNliBRZ7SxfO0YB6Ld9pPS9B/sQQi2uZd4UI09KGIh81LMqAbqKIRjPvlL 5zjPBQow==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1szJ8Q-0000000H3ba-3BW5; Fri, 11 Oct 2024 17:09:02 +0000 Received: from out-184.mta0.migadu.com ([91.218.175.184]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1szJ73-0000000H3OC-2lCC for linux-arm-kernel@lists.infradead.org; Fri, 11 Oct 2024 17:07:39 +0000 Date: Fri, 11 Oct 2024 10:07:24 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1728666453; 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=B7SnnnTfOwt4kWHiPAWUzLS15XAxy5TfsaE83NvMhaE=; b=GJws6XVEr6jYMDBApSbVk0SwWkV0U5j3dE4Z2bGBFsXKdio+v64vTPEW0yoqaGWny9nitT Jc8INvHNXmV9fLafK1AWciGDKPrF9Ztr5ldjWYz0MZvQT2Pf6+useQwi7nykgtxqvCJsxD Nm03XvHEGqkYbPRxskRUniNSxVuvDQ4= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Oliver Upton To: Shameer Kolothum Cc: kvmarm@lists.linux.dev, maz@kernel.org, catalin.marinas@arm.com, will@kernel.org, mark.rutland@arm.com, cohuck@redhat.com, eric.auger@redhat.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 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20241011075053.80540-1-shameerali.kolothum.thodi@huawei.com> X-Migadu-Flow: FLOW_OUT X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20241011_100738_057901_E347244B X-CRM114-Status: GOOD ( 28.41 ) 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 Hey Shameer, Thank you for posting this series. This'll help might cross-host migrations on arm64 a little less sketch :) On Fri, Oct 11, 2024 at 08:50:47AM +0100, Shameer Kolothum wrote: > Hi, > > On ARM64 platforms most of the errata workarounds are based on CPU > MIDR/REVIDR values and a number of these workarounds need to be > implemented by the Guest kernel as well. This creates a problem when > Guest needs to be migrated to a platform that differs in these > MIDR/REVIDR values even if the VMM can come up with a common minimum > feature list for the Guest using the recently introduced "Writable > ID registers" support. > > (This is roughly based on a discussion I had with Marc and Oliver > at KVM forum. Marc outlined his idea for a solution and this is an > attempt to implement it. Thanks to both and I take all the blame > if this is nowhere near what is intended/required) > > This RFC proposes a solution to handle the above issue by introducing > the following, > > 1. A new VM IOCTL, > KVM_ARM_SET_MIGRN_TARGET_CPUS _IOW(KVMIO, 0xb7, struct kvm_arm_migrn_cpus) > This can be used by the userspace(VMM) to set the target CPUs the > Guest will run in its lifetime. See patch #2 > 2. Add hypercall support for Guest kernel to retrieve any migration > errata bitmap(ARM_SMCCC_VENDOR_HYP_KVM_MIGRN_ERRATA) > The above will return the bitmaps in R0-R3 registers. See patch #4 > 3. The "capability" field in struct arm64_cpu_capabilities is a generated > one at present and may get renumbered or reordered. Hence, we can't use > this directly for migration errata bitmaps. Instead, introduced > "migartion_safe_cap", which has to be set statically for any > erratum that needs to be enabled and is safe for migration > purposes. See patches 3 & 6. > 4. Rest of the patches includes the plumbing required to populate the > errata bitmap based on the target CPUs set by the VMM and update the > system_cap based on it. > > ToDos:- > -We still need a way to handle the error in setting the invariant > registers(MIDR/REVIDR/AIDR) during Guest migration. Perhaps we can > handle it in userspace? This seems entirely reasonable. There's nothing KVM can do to unilaterally prevent userspace from migrating VMs between different implementations already, and the invariance of MIDR/REVIDR is just a speed bump and not an outright blocker. Ultimately this is now a contract between the VMM and guest, so we may as well let userspace advertise whatever implementation it wants in the ID registers. > Please take a look and let me know your thoughts. Looking at the guest side of things, it'd be nice if we hide the entire MIDR abstraction behind is_midr_in_range() et al and stop letting callers provide the MIDR. Internally that can find the MIDR of the current CPU or walk the array of MIDRs supplied by the hypervisor. Beyond that, we probably need a way to clue in userspace on the game in case it has some behaviors keyed off MIDR too. -- Thanks, Oliver