From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 656CC3932F9; Thu, 24 Sep 2026 18:23:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790274193; cv=none; b=Y29KsjeJon78Hsj9MH1VFZIJUwXuj4S6duRDJQIz+GA9SrA9FbzX3I7ErFxE7dmIv/dodaCrkSCKAQuUqIr3Qdscc37NimLpzeZtrehfjKh0WRF3JuKTVRHjnJdpnUYehDeoYkmmvRDav5daB3ROWJuhkHB1Wkc2y3CECG38xrg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790274193; c=relaxed/simple; bh=ThY+aOhqOAs0ChelKPf0sM0NHX9A6M0pDMIBNLYdFsQ=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=SqYf5Rjx6k+LH4gb8ktCAPS3TccqCzwIelylb9zvKWnNo7z8bqGAAUzzwv5qiqU798+X+yJc78lWpTsGzHaMABcasrUJcmjLYLt4qNjb9sbtna9Mzrimi3tW8L8JFxS6Hg7doK5rJuQPwkGfWCLZKe8+yKxDc/DJ4jaQac8jiVs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=edIIEwrW; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="edIIEwrW" Received: by smtp.kernel.org (Postfix) with ESMTPSA id F1CDA1F000FF; Thu, 24 Sep 2026 18:23:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1790274192; bh=1rT3iAcNKN3CIsNAZsMz38eVN8WYGGW5v5DII5ENAjk=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=edIIEwrWeWggBFTvgr+bbPHwZtpX7N39My3UWMq4+1+l5NRt0zCP77Pu80O5Z9Ok2 PyfgUkUTwEU+thWrqhUai0xQu+HRifkbZ7yAJn1McDoCFIFiWiEyuQTJPml6JpIn7d amqgFtOIiNI5u/q8A3a/cr3fJ/8H0PSVGAN7Jk1FdbAik4wQABSQrTon9qmS20uZKP +Ulo+sF1OxDgZLpRrMp5fdmXoHcr01h6EmfhN10/M/OUppPFNzQdB/bysfibyAR0uT 8nOYSXEQRvw0yAtQ7JBgVh6s8rgfoYwX2tRloaG4ywG6iDtP7emrmF0q9b7cvC5RKD SdQkKYydlnwFA== 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.98.2) (envelope-from ) id 1x9o69-0000000DA1f-3uMi; Thu, 24 Sep 2026 18:23:10 +0000 Date: Thu, 24 Sep 2026 19:23:09 +0100 Message-ID: <86ld8q4igi.wl-maz@kernel.org> From: Marc Zyngier To: Hao Zhang Cc: Oliver Upton , Fuad Tabba , Joey Gouly , Steffen Eiden , Suzuki K Poulose , Zenghui Yu , kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/2] KVM: arm64: pvtime: Don't lose stolen time on failed updates In-Reply-To: References: 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/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: 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: hao_zhang_kdev@163.com, oupton@kernel.org, fuad.tabba@linux.dev, joey.gouly@arm.com, seiden@linux.ibm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Mon, 21 Sep 2026 10:20:34 +0100, Hao Zhang wrote: > > From: Hao Zhang > > kvm_update_stolen_time() advances last_steal before checking whether > kvm_put_guest() successfully writes the updated value to guest memory. > > If the write fails, the updated stolen time is not visible to the guest, > but the corresponding run delay has already been consumed from KVM's > accounting state. A later successful update therefore starts from the > advanced last_steal value and permanently loses that interval. I'm sceptical. A "transient" write failure means that userspace has unmapped the page this should have been stored to. Userspace is in charge of the VM -- it literally is the owner. Why should we prevent it from shooting itself in the foot? Userspace can equally stop the vcpu from running, and this is "stolen time" that is not accounted for. M. -- Without deviation from the norm, progress is not possible.